用户故事映射

User Story Mapping

目录
用户故事映射

用户故事映射

User Story Mapping

杰夫 巴顿

Jeff Patton

奉献精神

Dedication

对于 Stacy、Grace 和 Zoe,他们是我最大的支持者,让我所有的努力都值得。

For Stacy, Grace, and Zoe who are my biggest supporters and make all my effort worthwhile.

并纪念我亲爱的同事兼导师卢克·巴雷特 (Luke Barrett)。卢克改变了我的生活,就像他改变了无数其他人一样。

And in memory of Luke Barrett, a dear colleague and mentor of mine. Luke made a difference in my life as he did countless others.

马丁福勒的前言

Foreword by Martin Fowler

马丁福勒

Martin Fowler

2014 年 6 月 18 日

敏捷软件开发兴起的有益后果之一是将大的需求集拆分成更小的块的概念。这些块——故事——使开发项目的进度更加可见。当一个产品逐个故事构建时,每个故事的实现都完全集成到软件产品中,每个人都可以看到产品的成长。通过使用对用户有意义的故事,开发人员可以通过确定接下来要构建的故事来引导项目。这种更高的可见性有助于鼓励用户更多地参与——他们不再需要等待一年或更长时间才能看到开发团队在做什么。

One of the beneficial consequences of the rise of Agile software development is the notion of splitting up large sets of requirements into smaller chunks. These chunks—stories—enable much more visibility into the progress of a development project. When a product is built story-by-story, with each story’s implementation fully integrated into the software product, everyone can see the product grow. By using stories that make sense to users, developers can steer the project by determining which stories to build next. This greater visibility helps encourage greater participation from users—no longer do they have to wait a year or more to see what the development team’s been up to.

但是这种分块有一些负面影响。其中之一是很容易忘记软件系统应该做什么的大局。您最终可能会得到一堆乱七八糟的碎片,无法组成一个连贯的整体。或者您可能最终构建了一个对用户没有真正帮助的系统,因为您因迷失在细节中而错过了所需内容的本质。

But this chunking has some negative consequences. One of these is that it’s easy to lose the big picture of what a software system should do. You can end up with a jumble of pieces that don’t fit into a coherent whole. Or you can end up building a system that isn’t really helpful to the users, because you’ve missed the essence of what’s needed by getting lost in the details.

故事地图是一种技术,它提供了一堆故事经常遗漏的大局。

Story mapping is a technique that provides the big picture that a pile of stories so often misses.

就是这样,真的——用一句话描述这本书。这句话带有很多价值的承诺。大图有助于与用户进行有效沟通,帮助所有相关人员避免构建不必要的功能,并为一致的用户体验提供方向。当我与 ThoughtWorks 的同事谈论他们如何开发他们的故事时,故事地图经常作为一项核心技术出现。他们通常是从 Jeff 举办的研讨会中学到这项技术的,因为他是开发这项技术并且最能传达这项技术的人。本书让更多人直接从源头上了解这项技术。

That’s it, really—the description of this book in a single sentence. And that sentence carries with it the promise of a lot of value. A big picture helps communicate effectively with users, it helps everyone involved avoid building unnecessary features, and it provides an orientation for a coherent user experience. When I talk to my colleagues at ThoughtWorks about what they do to develop their stories, story mapping regularly comes up as a core technique. Often they’ve learned that technique from workshops run by Jeff, because he’s the one who developed the technique and can best communicate it. This book allows more people to understand this technique directly from its source.

但这不仅仅是为名片或在线个人资料上有“业务分析师”字样的人准备的书。在采用敏捷方法的十年中,对我来说最大的失望也许是许多程序员将故事视为分析师与他们的单向交流的方式。从一开始,故事就应该引发对话. 如果你真的想想出有效的软件来支持一项活动,那么你需要将那些构建软件的人视为其功能的重要思想来源,因为程序员最了解软件的功能。程序员需要了解他们的用户正在努力实现什么,并且应该协作构建捕捉这些用户需求的故事。了解故事映射的程序员可以更好地了解更广泛的用户上下文,并可以参与构建软件——从而获得更好的工作。

But this isn’t just a book for people who have something like “business analyst” on their business card or online profile. Perhaps the biggest disappointment for me in the decade of the adoption of Agile methods is the way that many programmers see stories as a one-way communication from analysts to them. Right from the beginning, stories were supposed to spark conversations. If you really want to come up with effective software to support an activity, then you need to look to those who build software as a vital source of ideas for its capabilities, because it’s programmers who know best what software can do. Programmers need to understand what their users are trying to achieve and should collaborate in building the stories that capture those users’ needs. A programmer who understands story mapping can better see the broader user context and can participate in framing the software—leading to a better job.

当 Kent Beck(提出“故事”概念的人)提出他关于软件开发的想法时,他称沟通是高效团队的关键价值。故事是开发人员与使用他们作品的人之间进行交流的基石。故事地图组织和构建这些构建块,从而增强这种沟通过程——这是软件开发本身最关键的部分。

When Kent Beck (who originated the notion of a “story”) developed his ideas on software development, he called out communication as a key value of effective teams. Stories are the building blocks of communication between developers and those who use their work. Story maps organize and structure these building blocks, and thus enhance this communication process—which is the most critical part of software development itself.

艾伦·库珀的前言

Foreword by Alan Cooper

艾伦·库珀

Alan Cooper

2014 年 6 月 17 日

在玛丽·雪莱 (Mary Shelley) 著名的科幻小说《科学怪人》( Frankenstein ) 中,疯狂的弗兰肯斯坦博士用不同的死人碎片制造了一个生物,并用当时的新技术使这个生物复活。当然,我们知道这实际上是不可能的。你不能通过将随机的身体部位缝合在一起来创造生命。

In Mary Shelley’s famous science-fiction novel, Frankenstein, the mad Doctor Frankenstein builds a creature from disparate pieces of dead humans and brings the creature to life with the then-new technology of electricity. Of course, we know that this is not actually possible. You cannot create life by sewing together random body parts.

然而,这正是软件开发人员一直试图做的事情。他们为软件添加好的功能,一次一个,然后想知道为什么很少有用户喜欢他们的产品。难题的核心是开发人员将他们的构造方法用作设计工具,但两者不可互换。

Yet this is what software developers attempt to do all the time. They add good features to software, one at a time, and then wonder why few users love their product. The heart of the conundrum is that developers are using their construction method as a design tool, but the two are not interchangeable.

程序员一次构建软件一个功能是完全合理的。这是一个非常好的策略,经过多年的验证。多年来还被证明的是,当用作设计数字产品的行为和范围的方法时,一次一个功能会产生程序的弗兰肯斯坦怪物。

It’s entirely reasonable that programmers build software one feature at a time. That’s a perfectly good strategy, proven over the years. What has also been proven over the years is that, when used as a method for designing the behavior and scope of a digital product, one-feature-at-a-time yields a Frankenstein monster of a program.

虽然它们密切相关,但设计软件行为的实践和构建该软件的实践截然不同,并且通常由具有不同技能的不同人员执行。交互设计师花在观察用户和映射行为模式上的许多时间会让大多数程序员抓狂。相反,对大多数设计师来说,为算法苦苦挣扎的时间太孤独了。

While they are intimately related, the practice of designing software behavior and the practice of building that software are distinctly different, and are typically performed by different people with different skill sets. The many hours that interaction designers spend observing users and mapping behavior patterns would drive most programmers batty. Conversely, the hours of sweating over algorithms are too solitary for most designers.

但是,当设计和开发这两种实践方式协作时,这项工作就会变得充满活力,并有可能创造出一种活生生的、会呼吸的产品。团队合作为怪物注入了生命,让人们爱上了它。

But when the two strains of practice—design and development—collaborate, the work becomes electric and has the potential to create a living, breathing product. Teamwork breathes life into the monster and makes people love it.

虽然协作的想法既不新鲜也不是特别有见地,但实际上很难有效地做到这一点。开发人员的工作方式——他们的节奏、语言和节奏——与交互设计师的工作方式截然不同。

While the idea of collaboration is neither new nor particularly insightful, it is actually very difficult to do effectively. The way that developers work—their pace, language, and rhythm—is quite different from that of interaction designers.

这两个领域的从业者都很强,有能力,而且内部纪律严明,但他们有一个共同的弱点。用编程术语表达设计问题真的很难,用设计术语表达开发问题同样困难。这两个姊妹学科缺乏共同语言。而这两个学科之间的交汇点正是杰夫·巴顿 (Jeff Patton) 居住的地方。

Practitioners in each of the two fields are strong, capable, and internally well disciplined, yet they share a single, common weakness. It is really hard to express a design problem in programming terms, and it is equally hard to express a development problem in design terms. The two sister disciplines lack a common tongue. And that junction between the two disciplines is precisely where Jeff Patton lives.

Jeff 的故事映射方法对开发人员很有意义,对设计师也同样有意义。故事地图是我们数字时代的罗塞塔石碑。

Jeff’s method of story mapping makes sense to developers, and it makes equal sense to designers. Story mapping is the Rosetta Stone for our digital age.

尽管有相反的说法,敏捷开发并不是一个非常有用的设计工具。这是一种设计友好的开发思维方式,这是一件非常好的事情,但它本身不会让您获得用户喜爱的产品。另一方面,我们已经多次看到好的设计、有据可查的文档提供给开发人员(无论是否敏捷),他们设法在实施过程中扼杀了设计的本质。

Despite protestations to the contrary, Agile development is not a very useful design tool. It is a way of thinking about development that is design-friendly, which is a very good thing, but by itself it won’t get you to a product that users love. On the other hand, so many times we have seen good designs, well documented, given to developers—Agile or not—who manage to kill the essence of the design in the process of implementation.

巴顿的故事映射方法是跨越这个鸿沟的桥梁。交互设计就是要找到用户的真相并将其作为叙述来讲述。软件开发就是将这些叙述分解成微小的功能块,然后实施和集成它们。在这个复杂的过程中,叙事的本质很容易就溜走了。是的,功能实现了,但是病人死在了手术台上。

Patton’s story mapping approach is the bridge over this chasm. Interaction design is all about finding the user’s truth and telling it as a narrative. Software development is all about breaking those narratives into tiny, functional chunks and implementing and integrating them. It’s so ridiculously easy for the essence of the narrative to slip away during this complex process. Yes, the functions are implemented, but the patient dies on the operating room table.

通过绘制用户故事,设计保留了其叙事结构,但仍可以解构以有效实施。设计师的故事是用户故事的形式化版本,在整个开发过程中保持不变。

By mapping out the user’s stories, the design retains its narrative structure yet can still be deconstructed for effective implementation. The designer’s story, which is a formalized version of the user’s story, remains intact throughout the development.

传统的企业界已经证明,两三百人的团队几乎不可能打造出人们喜爱的产品。与此同时,创业社区已经证明,四五个人的团队可以打造出人们喜爱的小产品,但即使是这些小产品最终也会变大并失去火花。我们面临的挑战是创建人们喜爱的大型软件。大型软件为大量受众提供复杂的、商业上可行的工作。要让这样的软件既有趣又易于学习是非常困难的。

The conventional corporate world has proven that it is nearly impossible for a team of two or three hundred people to build a product that people love. Meanwhile the startup community has proven that a team of four or five people can build small products that people love, but even these little products eventually grow big and lose their spark. The challenge we face is creating big software that people love. Big software serves large audiences doing complex, commercially viable jobs. It’s ridiculously hard to make such software fun to use and easy to learn.

我们要构建不是弗兰肯斯坦怪物的大型软件的唯一方法是学习如何整合软件设计和开发的学科。没有人比 Jeff Patton 更了解如何做到这一点。

The only way we are going to build big software that is not a Frankenstein monster is by learning how to integrate the disciplines of software design and development. Nobody knows how to do that better than Jeff Patton.

马蒂·卡根 (Marty Cagan) 的前言

Foreword by Marty Cagan

马蒂凯根

Marty Cagan

2014 年 6 月 18 日

我非常幸运能够与世界上许多最优秀的技术产品团队一起工作。人们每天都在创造您使用和喜爱的产品。真正改变世界的团队。

I’ve had the extremely good fortune to be able to work with many of the very best technology product teams in the world. People creating the products you use and love every day. Teams that are literally changing the world.

我也受邀尝试帮助表现不佳的公司。初创公司竞相在资金用完之前获得一些牵引力。大公司努力复制他们的早期创新。团队未能持续为其业务增加价值。领导者对从想法到现实需要多长时间感到沮丧。工程师们对他们的产品负责人感到恼火。

I’ve also been brought in to try to help companies that are not doing so well. Startups racing to get some traction before the money runs out. Larger companies struggling to replicate their early innovation. Teams failing to continuously add value to their business. Leaders frustrated with how long it takes to go from idea to reality. Engineers exasperated with their product owners.

我所了解到的是,最好的产品公司创造技术产品的方式与其他公司之间存在着深刻的差异。我不是说细微差别。我指的是从领导者的行为方式到团队授权水平的方方面面;团队合作的方式;组织如何考虑资金、人员配备和生产产品;对文化;了解产品、设计和工程如何协作,为他们的客户发现有效的解决方案。

What I’ve learned is that there is a profound difference between how the very best product companies create technology products, and the rest. And I don’t mean minor differences. I mean everything from how leaders behave to the level of empowerment of teams; to the way teams work together; to how the organization thinks about funding, staffing, and producing products; to the culture; to how product, design, and engineering collaborate to discover effective solutions for their customers.

这本书的标题是User Story Mapping,但您很快就会发现它所涉及的远不止这种强大而简单的技术。这本书的核心是团队如何协作、沟通,并最终想出好东西来构建。

This book is titled User Story Mapping, but you’ll soon see it is about much more than this powerful yet simple technique. This book gets to the heart about how teams collaborate, communicate, and ultimately come up with good stuff to build.

你们中的许多人从未有机会近距离了解强大的产品团队是如何运作的。您可能知道的只是您在公司或以前工作过的地方看到的情况。所以我想在这里做的是试着让你了解最好的球队与其他球队有多么不同。

Many of you have never had a chance to see up close how a strong product team operates. All you may know is what you’ve seen at your company or where you’ve worked before. So what I’d like to do here is to try to give you a flavor of just how different the best teams are from the rest.

感谢 Ben Horowitz 的《好产品经理,坏产品经理》,以下是强产品团队和弱产品团队之间的一些重要区别:

With a grateful nod to Ben Horowitz’s Good Product Manager, Bad Product Manager, here’s a glimpse into some of the important differences between strong product teams and weak teams:

优秀的团队拥有令人信服的产品愿景,他们以传教士般的热情追求这一愿景。糟糕的团队是雇佣军。

优秀的团队从他们的记分卡 KPI、观察客户的挣扎、分析客户使用他们的产品产生的数据以及不断寻求应用新技术来解决实际问题中获得灵感和产品创意。糟糕的团队从销售和客户那里收集需求。

优秀的团队了解他们的主要利益相关者是谁,他们了解这些利益相关者所处的制约因素,并且他们致力于发明不仅对用户和客户有效,而且在业务约束范围内有效的解决方案。糟糕的团队从利益相关者那里收集需求。

优秀的团队精通多种技术,可以快速尝试产品创意,以确定哪些产品真正值得打造。糟糕的团队召开会议来生成优先路线图。

优秀的团队喜欢与全公司聪明的思想领袖进行头脑风暴讨论。当团队外的人胆敢建议他们做某事时,糟糕的团队会被冒犯。

优秀的团队让产品、设计和工程部门并肩工作,并接受功能、用户体验和支持技术之间的取舍。不好的团队坐在各自的职能区域,要求其他人以文件和安排会议的形式提出对他们服务的要求。

优秀的团队不断尝试新想法以进行创新,但这样做的方式可以保护收入和品牌。糟糕的团队仍在等待运行测试的许可。

优秀的团队坚持认为他们拥有创造成功产品所必需的技能组合,例如强大的交互设计。糟糕的团队甚至不知道交互设计师是什么。

优秀的团队确保他们的工程师每天都有时间尝试发现原型,这样他们就可以就如何让产品变得更好发表自己的想法。糟糕的团队在冲刺计划期间向工程师展示原型,以便他们进行估算。

优秀的团队每周都会与最终用户和客户直接接触,以更好地了解他们的客户,并了解客户对他们最新想法的反应。糟糕的团队认为他们是客户。

优秀的团队知道,他们最喜欢的许多想法最终不会为客户服务,即使是那些可能需要多次迭代才能达到他们提供预期结果的点。糟糕的团队只会按照路线图构建内容,并对会议日期和确保质量感到满意。

优秀的团队了解对速度的需求以及快速迭代是创新的关键,并且他们了解这种速度来自正确的技术而不是强迫劳动。糟糕的团队抱怨他们工作缓慢,因为他们的同事工作不够努力。

优秀的团队在评估请求并确保他们拥有切实可行的解决方案后,会做出高度诚信的承诺,这些解决方案将真正为客户和企业服务。糟糕的团队抱怨自己是一家以销售为导向的公司。

优秀的团队会检测他们的工作,以便他们可以立即了解他们的产品是如何被使用的,并根据数据做出调整。糟糕的团队认为分析和报告是“可有可无的”。

优秀的团队会持续集成和发布,因为他们知道源源不断的较小版本会为他们的客户提供更稳定的解决方案。糟糕的团队在痛苦的集成阶段结束时手动测试,然后立即发布所有内容。

优秀的团队会关注他们的参考客户。糟糕的团队对竞争对手很着迷。

优秀的团队在对业务 KPI 产生重大影响时庆祝。糟糕的团队在他们终于发布一些东西时庆祝。

Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries.

Good teams get their inspiration and product ideas from their scorecard KPIs, from observing customers struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers.

Good teams understand who their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that not only work for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders.

Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps.

Good teams love to have brainstorming discussions with smart thought leaders from across the company. Bad teams get offended when someone outside their team dares to suggest they do something.

Good teams have product, design, and engineering sit side-by-side, and embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their respective functional areas, and ask that others make requests for their services in the form of documents and scheduling meetings.

Good teams are constantly trying out new ideas in order to innovate, but doing so in ways that protect the revenue and the brand. Bad teams are still waiting for permission to run a test.

Good teams insist they have the skill sets necessary to create winning products, such as strong interaction design. Bad teams don’t even know what interaction designers are.

Good teams ensure that their engineers have time to try out the discovery prototypes every day so that they can contribute their thoughts on how to make the product better. Bad teams show the prototypes to the engineers during sprint planning so they can estimate.

Good teams engage directly with end users and customers every week to better understand their customers, and to see the customer’s response to their latest ideas. Bad teams think they are the customer.

Good teams know that many of their favorite ideas won’t end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome. Bad teams just build what’s on the roadmap and are satisfied with meeting dates and ensuring quality.

Good teams understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed comes from the right techniques and not forced labor. Bad teams complain they are slow because their colleagues are not working hard enough.

Good teams make high-integrity commitments after they’ve evaluated the request and ensured they have a viable solution that will actually work for the customer and the business. Bad teams complain about being a sales-driven company.

Good teams instrument their work so that they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consider analytics and reporting a “nice to have.”

Good teams integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers. Bad teams test manually at the end of a painful integration phase and then release everything at once.

Good teams obsess over their reference customers. Bad teams obsess over competitors.

Good teams celebrate when they achieve a significant impact to the business KPIs. Bad teams celebrate when they finally release something.

我知道您可能想知道这一切与故事地图有什么关系。我想你会感到惊讶。这正是我喜欢故事地图的原因。

I realize you might be wondering what all this has to do with story maps. I think you’ll be surprised. And that’s precisely why I am a fan of story maps.

我只见过少数敏捷专家,我认为他们有资格真正帮助一个认真的产品团队将其游戏提升到公司需要和应得的水平。杰夫巴顿就是其中之一。我观察到他在发现产品的过程中与团队一起在战壕中亲身实践。我把他介绍给公司,因为他很有效率。团队喜欢他,因为他知识渊博但又谦虚。

I have met only a few Agile experts whom I consider qualified to actually help a serious product team raise its game to the level its company needs and deserves. Jeff Patton is one of them. I have observed him working hands on in the trenches with teams in the midst of product discovery. I introduce him into companies because he is effective. Teams love him because he is knowledgeable yet humble.

产品经理收集并记录需求,设计师争先恐后地在产品上涂点口红,工程师躲在地下室里编码的日子,对于最好的团队来说早已一去不复返了。他们也该离开您的团队了。

The days of product managers gathering up and documenting requirements, designers scrambling just to put some lipstick on the product, and engineers sheltered in the basement, coding, are long gone for the best teams. And it’s time they are gone for your team, too.

前言

Preface

生活在其中,游泳在其中,欢笑在其中,爱在其中/去除轮廓板上令人尴尬的污渍,没错/它招待来访的亲戚,它把三明治变成宴会。

Tom Waits,“站起来”

Live in it, swim in it, laugh in it, love in it / Removes embarrassing stains from contour sheets, that’s right / And it entertains visiting relatives, it turns a sandwich into a banquet.

Tom Waits, “Step Right Up”

这本书应该是一件小事……一本小册子,真的。

This book was supposed to be a small thing…a pamphlet, really.

我开始写一个简单的实践,我称之为故事映射。我和许多其他人一起构建简单的地图,以帮助我们与他人合作并想象使用产品的体验。

I set out to write about a simple practice I called story mapping. I, and lots of other folks, build simple maps to help us work together with others and to imagine the experience of using a product.

故事地图让我们专注于用户和他们的体验,结果是更好的对话,最终是更好的产品。

Story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product.

没有标题的图片

构建地图非常简单。我将与其他人一起讲述一个产品的故事,将用户在故事中采取的每一个重大步骤以从左到右的顺序写在便签上。然后,我们将回过头来讨论每个步骤的细节,并将这些细节写在便利贴上,并垂直放置在每个步骤下方。结果是一个简单的网格状结构,从左到右讲述一个故事,并从上到下分解成细节。它既有趣又快速。这些细节使我们的敏捷开发项目的故事积压得更好。

Building a map is dead simple. Working together with others, I’ll tell the story of a product, writing each big step the users take in the story on sticky notes in a left-to-right flow. Then, we’ll go back and talk about the details of each step, and write those details down on sticky notes and place them vertically under each step. The result is a simple grid-like structure that tells a story from left to right, and breaks it into details from top to bottom. It’s fun and fast. And those details make a better backlog of stories for our Agile development projects.

写一本关于这个的书有多复杂?

How complicated could writing a book about this be?

但事实证明,即使是简单的事情也可以非常复杂。写下为什么要构建故事地图、构建故事地图时会发生什么以及使用故事地图的所有不同方式花了我很多页。这个简单的练习比我想象的要多。

But it turns out that even the simple things can be pretty sophisticated. And writing about why you would want to build a story map, what’s going on when you build one, and all the different ways you can use one took me a lot of pages. There was more to this simple practice than I thought.

如果您使用的是敏捷开发流程,您可能会用用户故事填充积压工作。我原以为,既然讲故事是一种常见的做法,那么在这本书中写这些故事对我来说是浪费时间。但是我错了。自肯特·贝克 (Kent Beck) 首次描述故事以来的十五年里,它们比以往任何时候都更受欢迎,也更容易被误解和误用。那样令我伤心。而且,更重要的是,它扼杀了我们从故事地图中获得的所有好处。

If you’re using an Agile development process, you’re likely filling backlogs with user stories. I’d assumed that since stories were such a common practice, it’d be a waste of time for me to write about them in this book. But I was wrong. In the decade and a half since stories were first described by Kent Beck, they’re more popular—and more misunderstood and misused—than ever before. That makes me sad. And, what’s more, it kills all the benefit we get from story mapping.

因此,在本书中,我想纠正尽可能多的关于故事及其在敏捷和精益软件开发中的使用方式的重大误解。这就是为什么,用 Tom Waits 的话来说,我把这个“三明治变成了宴会”。

So, in this book, I would like to correct as many big misconceptions as I can about stories and the way they’re used in Agile and Lean software development. That’s why, in the words of Tom Waits, I’ve turned this “sandwich into a banquet.”

为什么是我?

Why Me?

我喜欢做东西。激励我的是我从创建一个软件并看到人们使用它并从中受益所获得的快乐。我是一个不情愿的方法论者。我发现我需要学习过程和实践如何工作才能更好地掌握它们。在从事软件开发 20 多年之后,我现在才开始学习如何教授我所学的知识。我知道我所教的是一个移动的目标。我的理解每周都在变化。如何最好地解释它的变化几乎一样快。所有这些都让我多年来没有写一本书。

I like making things. What motivates me is the joy I get from creating a piece of software and seeing people use it and benefit from it. I’m a reluctant methodologist. I found I needed to learn how process and practice work to get better at them. I’m only now learning after 20-plus years in software development how to teach what I’ve learned. And I know that what I teach is a moving target. What I understand changes every week. How best to explain it changes almost as fast. All that’s kept me from writing a book for years.

但现在是时候了。

But it’s time.

故事和故事地图是个好主意。他们让很多人受益。他们让自己的生活更美好,他们打造的产品也更美好。但是,虽然有些人的生活越来越好,但与以往任何时候相比,越来越多的人都在为故事而苦苦挣扎。我想帮助阻止它。

Stories and story maps are such a good idea. They’ve benefited so many people. They’ve made their lives better, and the products they build better. But while some people’s lives are getting better, there are more people struggling with stories than ever before. I want to help stop that.

这本书是我可以提供帮助的东西。而且,即使它改善了少数人的工作生活,我也会庆祝。

This book is something I can make to help. And, if it improves the work lives of even a few, I’ll celebrate.

如果您正在为故事而苦苦挣扎,这本书适合您

This Book Is for You If You’re Struggling with Stories

由于如此多的组织采用了敏捷和精益流程,以及随之而来的故事,您可能会因对故事的误解而陷入一个或多个陷阱。像这样的陷阱:

Because so many organizations have adopted Agile and Lean processes, and stories along with them, you may fall into one or more of the traps caused by misconceptions about stories. Traps like these:

  • 因为故事让您专注于构建小事物,所以很容易忽视大局。结果通常是“弗兰肯产品”,使用该产品的每个人都清楚它是由不匹配的零件组装而成的。
  • Because stories let you focus on building small things, it’s easy to lose sight of the big picture. The result is often a “Franken-product” where it’s clear to everyone using the product that it’s assembled from mismatched parts.
  • 当您构建任何重要的产品时,构建一个接一个的小东西会让人们想知道您什么时候可以完成,或者您将交付什么。如果你是建造者,你也会想知道。
  • When you’re building a product of any significant size, building one small thing after another leaves people wondering when you’ll ever be done, or what exactly you’ll deliver. If you’re the builder, you wonder, too.
  • 因为故事是关于对话的,所以人们用这个想法来避免写下任何东西。然后他们忘记了他们在谈话中谈论和同意的内容。
  • Because stories are about conversations, people use that idea to avoid writing anything down. Then they forget what they talked about and agreed to in the conversations.
  • 因为好故事应该有验收标准,所以我们专注于编写验收标准,但对于需要构建的内容仍然没有达成共识。因此,团队无法在他们计划的时间范围内完成他们计划的工作
  • Because good stories are supposed to have acceptance criteria, we focus on getting acceptance criteria written, but there’s still not a common understanding of what needs to be built. As a consequence, teams don’t finish the work they plan on in the timeframe they planned to.
  • 因为好的故事应该是从用户的角度来写的,有很多部分是用户看不到的,所以团队成员争辩说“我们的产品没有用户,所以用户故事在这里行不通。
  • Because good stories are supposed to be written from a user’s perspective, and there are lots of parts that users never see, team members argue that "our product doesn’t have users, so user stories won’t work here."

如果您掉进了这些陷阱中的任何一个,那么我会首先尝试消除导致这些陷阱的误解。您将学习如何从大局着眼,如何从大局(和小局)进行计划和估算,以及如何就用户想要完成的事情以及软件的好坏进行富有成效的对话需要帮助他们。

If you’ve fallen into any of those traps, then I’ll try to wipe away the misconceptions that lead to those traps in the first place. You’ll learn how to think of the big picture, how to plan and estimate in the large (and in the small), and how to have productive conversations about what users are trying to accomplish, as well as what a good piece of software needs to do to help them.

谁应该读这本书?

Who Should Read This Book?

你应该,当然。特别是如果你买了它。一方面,我认为您进行了明智的投资。如果你只是借用它,你应该现在就订购自己的,并在新的到达你家时归还你借用的那个。

You should, of course. Especially if you bought it. I, for one, think you’ve made a wise investment. If you’re just borrowing it, you should order your own now, and return the one you’ve borrowed when the new one arrives at your door.

然而,阅读本书为担任特定角色的从业者提供了特定的原因和好处:

However, reading this book offers specific reasons and benefits for practitioners in specific roles:

  • 商业产品公司的产品经理和用户体验 (UX) 从业者应该阅读本书,以帮助他们弥合思考整体产品和用户体验与思考战术计划和积压项目之间的差距。如果您一直在努力从您想象的愿景到您的团队可以构建的细节,那么故事地图将有所帮助。如果您一直在努力帮助他人想象您的产品用户的体验并产生同理心,那么故事地图将有所帮助。如果你一直在努力寻找如何将良好的用户体验和产品设计实践结合起来,这本书会有所帮助。如果您一直在努力将精益创业式的实验融入您的工作方式,那么本书将会有所帮助。
  • Product managers and user experience (UX) practitioners in commercial product companies should read this book to help them bridge the gap between thinking about whole products and user experience and thinking about tactical plans and backlog items. If you’ve been struggling to get from the vision you’re imagining to the details your teams can build, story maps will help. If you’ve been struggling to help others imagine the experience of—and empathize with—the users of your product, story mapping will help. If you’ve been struggling to figure out how to incorporate good UX and product design practice, this book will help. If you’ve been working to incorporate Lean Startup–style experimentation in the way you work, this book will help.
  • 信息技术 (IT) 组织的产品所有者、业务分析师和项目经理应该阅读本书,以帮助他们弥合内部用户、利益相关者和开发人员之间的鸿沟。如果您一直在努力说服公司中的许多利益相关者达成一致,那么故事地图会有所帮助。如果您一直在努力帮助开发人员了解全局,那么故事地图会有所帮助。
  • Product owners, business analysts, and project managers in information technology (IT) organizations should read this book to help them bridge the gap between their internal users, stakeholders, and developers. If you’ve been struggling to convince lots of stakeholders in your company to get on the same page, then story maps will help. If you’ve been struggling to help developers see the big picture, story maps will help.
  • 以帮助个人和团队改进为目标的敏捷和精益过程教练应该阅读本书。并且,正如您所做的那样,想想您组织中的人们对故事的误解。使用本书中描述的故事、简单练习和实践来帮助您的团队改进。
  • Agile and Lean process coaches with the goal of helping individuals and teams improve should read this book. And, as you do, think about the misconceptions people in your organization have about stories. Use the stories, simple exercises, and practices described in this book to help your teams improve.
  • 其他人。在使用敏捷流程时,我们通常会寻求产品所有者或业务分析师等角色来指导大量故事工作,但有效使用故事需要每个人都掌握基础知识。当人们不了解基本知识时,您会听到抱怨“故事写得不好”或“太大”或“没有足够的细节”。这本书会有所帮助,但不是以你想的方式。您和其他所有人都会了解到,故事并不是编写更好需求的一种方式,而是一种组织和进行更好对话的方式。这本书将帮助您了解您应该进行什么样的对话,以帮助您在需要时获得所需的信息。
  • Everyone else. When using Agile processes, we often look to roles like product owners or business analysts to steer a lot of the work with stories, but effective use of stories requires that everyone get the basics. When people don’t understand the basics, you hear complaints that “stories aren’t well written” or that they’re “too big,” or that they “don’t have enough detail.” This book will help, but not in the way you think. You and everyone else will learn that stories aren’t a way to write better requirements, but a way to organize and have better conversations. This book will help you understand what kinds of conversations you should be having to help you get the information you need when you need it.

我希望您认同我刚才描述的一个或多个群体。如果您不这样做,请将这本书送给这样做的人。

I’m hoping you identify with one or more of the groups I just described. If you don’t, give this book to someone who does.

如果你这样做,让我们开始吧。

If you do, let’s get started.

本书中使用的一些约定

A Few Conventions Used in This Book

我怀疑这不是您读过的唯一一本关于软件开发的书,因此您应该不会感到惊讶。

I suspect this isn’t the only book on software development you’ve ever read, so nothing should surprise you.

每章内的标题引导您了解主题

The Headings Inside Each Chapter Guide You Through the Subject

使用它们来找到您的方式或跳过您现在不感兴趣的内容。

Use them to find your way or skip over stuff you’re not interested in right now.

关键点看起来像这样。想象一下,我说这些比其他所有文字都大声。

Key points look like this. Imagine me saying these a bit louder than all the other text.

如果您正在略读,请阅读要点。如果您喜欢它们,或者它们不是很明显,请阅读它们前后的文字。这应该让他们清楚。

If you’re skimming, read the key points. If you like them, or they’re not dead obvious, read the text before and after them. That should make them clear.

这本书被组织成特定的部分。您可以一次阅读一个部分,或者使用这些部分来帮助您找到应对当前特定挑战的想法。

The book is organized into specific sections. You could read it a section at a time, or use the sections to help you find ideas for a specific challenge you have right now.

本书是如何组织的

How This Book Is Organized

不久前我买了一台很酷的新型彩色激光打印机。我打开盒子,打印机上面放着一本小册子,上面用红色大字写着“请先阅读本文”。我想知道,“我真的应该先读这个吗?” 因为我通常不照我说的做。但我很高兴我这么做了,因为打印机内部的各个地方都有很多塑料防护装置,以保证它在运输过程中的安全,如果我在取下它们之前插上电源,我可能会损坏打印机。

I bought a cool new color laser printer a while back. I opened the box, and sitting on top of the printer was a pamphlet with “Read This First” in big red letters on it. I wondered, “Should I really read this first?” because I usually don’t do as I’m told. But I’m glad I did, because there were lots of plastic guards in various places inside the printer to keep it safe during shipping, and if I’d plugged it in before removing them, I might have damaged the printer.

这个故事听起来像是一个切线,但事实并非如此。

This story might sound like a tangent, but it’s not.

本书包含“首先阅读此书”一章,因为我将在本书的其余部分中使用两个关键概念和相关词汇。我希望您在开始之前在脑海中有这些概念。如果您在理解它们之前就开始使用故事地图,我无法保证您的安全。

This book contains a “Read This First” chapter because there are two critical concepts and associated vocabulary that I’ll use throughout the rest of the book. I’d like you to have those concepts in your head before you get started. If you start to story map before you understand them, I can’t guarantee your safety.

从 10,000 英尺绘制故事地图

Story Mapping from 10,000 Feet

1章到第4章将为您提供故事地图的高级视图。如果您已经使用故事一段时间并且之前玩过故事地图,那么本节应该足以让您立即开始。

Chapters 14 will give you a high-level view of story mapping. If you’ve been using stories for a while and played with a story map before, this section should give you enough to get going right away.

第 5 章提供了一个极好的练习,可帮助您学习用于创建出色故事地图的关键概念。在你的办公室与一群人一起尝试,每个参与的人都会得到它。我向您保证,他们为您的产品创建的地图之后会更好。

Chapter 5 gives you a nifty exercise to help you learn the key concepts used to create a great story map. Try it out with a group in your office, and everyone who participates will get it. And I promise you the maps they create for your products will come out better afterward.

探索用户故事

Grokking User Stories

6章到第12章讲述了故事背后的故事、它们的真正作用以及如何在敏捷和精益项目中充分利用它们。内部故事地图包含许多可用于推动日常开发的小故事。即使您是一名敏捷老手,我也保证您会学到一些您还不知道的故事。而且,如果您是故事的新手,您将学到足够多的知识,足以让办公室里的敏捷专家大吃一惊。

Chapters 612 tell the story behind stories, how they really work, and how to make good use of them in Agile and Lean projects. Inside story maps are lots of little stories you can use to drive day-to-day development. Even if you’re an Agile veteran, I promise you’ll learn something about stories you didn’t already know. And, if you’re new to stories, you’ll learn enough to surprise the Agile know-it-alls at your office.

更好的积压

Better Backlogs

1315章深入探讨了故事的生命周期。我将讨论帮助您使用故事和故事地图的具体实践,从重大机会开始,然后通过发现工作确定充满故事的积压工作,这些故事描述了一个可行的产品。您将了解故事地图和许多其他实践如何在整个过程中为您提供帮助。

Chapters 1315 dive deep into the lifecycle of a story. I’ll discuss specific practices that help you use stories and story maps, starting with big opportunities and moving through the discovery work to identify a backlog full of stories that describe a viable product. You’ll learn how story maps and lots of other practices can help you every step of the way.

更好的建筑

Better Building

16章到第18章深入探讨了在战术上、逐个迭代或逐个冲刺地使用故事。您将学习如何准备故事、在构建故事时集中注意力、真正完成它们,以及如何真正从您转换为工作软件的每个故事中学习。

Chapters 1618 dive deeper into using stories tactically, iteration-by-iteration or sprint-by-sprint. You’ll learn how to get stories ready, to pay attention while they’re built, to really get them done, and to really learn from each story you convert to working software.

我发现很多软件开发书籍的最后几章都是多余的垃圾。我通常可以忽略它们。不幸的是,我没有写任何这些章节。你需要阅读整本书。我对您唯一的安慰是,您将从每一章中获得一些有用的块,您可以立即投入使用。

I find that the last few chapters of many software development books are the extra junk. I can usually ignore them. Unfortunately, I didn’t write any of those chapters. You’ll need to read the whole book. My only consolation to you is that you’ll get some useful nuggets out of every chapter that you can put to work right away.

让我们开始吧。

Let’s get to it.

Safari® 在线图书

Safari® Books Online

笔记

Note

Safari Books Online是一个按需点播的数字图书馆,以书籍和视频形式提供来自世界技术和商业领域领先作者的专家内容。

Safari Books Online is an on-demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and business.

技术专业人士、软件开发人员、网页设计师以及商业和创意专业人士使用 Safari Books Online 作为他们研究、解决问题、学习和认证培训的主要资源。

Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training.

Safari Books Online为企业政府教育和个人提供一系列计划和定价。

Safari Books Online offers a range of plans and pricing for enterprise, government, education, and individuals.

会员可以访问来自 O'Reilly Media、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Focal Press、Cisco Press、John Wiley & Sons、Syngress、Morgan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones & Bartlett、Course Technology 等数百。有关 Safari Books Online 的更多信息,请在线访问我们。

Members have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, and hundreds more. For more information about Safari Books Online, please visit us online.

如何联系我们

How to Contact Us

请将有关本书的评论和问题发送给出版商:

Please address comments and questions concerning this book to the publisher:

奥莱利媒体公司
1005 Gravenstein 公路北
塞瓦斯托波尔, CA 95472
800-998-9938(美国或加拿大)
707-829-0515(国际或本地)
707-829-0104(传真)

我们有本书的网页,其中列出了勘误表、示例和任何其他信息。您可以访问此页面http://bit.ly/user-story-mapping

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://bit.ly/user-story-mapping.

要对本书发表评论或提出技术问题,请发送电子邮件至

To comment or ask technical questions about this book, send email to .

有关我们的书籍、课程、会议和新闻的更多信息,请访问我们的网站http://www.oreilly.com

For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.

在 Facebook 上找到我们:http: //facebook.com/oreilly

Find us on Facebook: http://facebook.com/oreilly

在 Twitter 上关注我们:http: //twitter.com/oreillymedia

Follow us on Twitter: http://twitter.com/oreillymedia

在 YouTube 上观看我们:http ://www.youtube.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

先读这个

Read This First

这本书没有简介。

This book has no introduction.

是的,你看的没错。现在,您可能会立即问自己,“为什么 Jeff 的书没有介绍?他忘记写了吗?这么多年了,他是不是开始滑倒了?!狗吃了吗?”

Yes, you read that right. Now, you might immediately ask yourself, “Why doesn’t Jeff’s book have an introduction? Did he forget to write it? Is he beginning to slip after all these years?! Did the dog eat it?”

不,我没忘记给这本书写个介绍。而且,不,我没有开始滑倒。至少我不认为我是。我的狗没有吃它(虽然我女儿的豚鼠看起来很可疑)。只是我长期以来一直认为作者花了太多时间来说服我应该读他们的书,而引言中有大量的说服力。大多数书籍的内容通常要到第 3 章才开始。而且我敢肯定,这样做的不仅是我,而且我通常会跳过介绍。

No, I didn’t forget to write an introduction to this book. And, no, I’m not beginning to slip. At least I don’t think I am. And my dog didn’t eat it (although my daughter’s guinea pig looks suspicious). It’s just that I’ve long believed that authors spend too much time convincing me I should read their book, and a great deal of that convincing lives in the introduction. The meat of most books usually doesn’t start until Chapter 3. And I’m sure it’s not only me who does this, but I usually skip the introduction.

这本书实际上是从这里开始的。

This book actually starts here.

你不能跳过这个,因为它确实最重要的部分。事实上,如果你能从这本书中得到两点,我会很高兴。这两点就在本章的此处:

And you’re not allowed to skip this because it really is the most important part. In fact, if you only get two points from this book, I’ll be happy. And those two points are right here in this chapter:

  • 使用故事的目的不是为了写出更好的故事。
  • The goal of using stories isn’t to write better stories.
  • 产品开发的目标不是制造产品。
  • The goal of product development isn’t to make products.

让我解释。

Let me explain.

电话游戏

The Telephone Game

我相信你还记得你小时候玩过这种奇怪的“电话游戏”,你在这个游戏中对某人耳语,对方又对其他人耳语,如此反复,直到最后一个人说出完全乱码的信息每个人都笑了。今天,我的家人仍然在家里和我的孩子围坐在餐桌旁玩这个游戏。家长注意:这是一个很好的活动,可以让孩子们厌倦成人晚餐的谈话。

I’m sure you remember when you were a kid and you played this weird “telephone game” where you whispered something to somebody, who whispered it to someone else, and so on around the group, until the last person reveals the totally garbled message and everyone laughs. Today, my family still plays this game at home with my kids around the dinner table. Note to parents: this is a good activity to occupy kids bored with adult dinner conversation.

在成年人的世界里,我们继续着这个游戏——只是我们不再窃窃私语。我们编写冗长的文档并创建看起来很正式的演示文稿,然后将其交给某个人,而这个人会从中得到与我们预期完全不同的东西。然后那个人使用该文档创建更多文档以提供给不同的人。然而,与我们小时候玩的那个游戏不同,我们并没有在最后都笑。

In the grown-up world, we’ve continued this game—only we don’t whisper to each other. We write lengthy documents and create official-looking presentations that we hand off to someone, who proceeds to get something completely different out of it than we intended. And that person uses that document to create more documents to give to different people. However, unlike that game we played as kids, we don’t all laugh at the end.

当人们阅读书面说明时,他们会做出不同的解释。如果您觉得这有点难以置信(毕竟是书面形式!),那么让我向您展示一些说明错误非常非常严重的示例。

When people read written instructions, they interpret them differently. If you find that a little hard to believe (it’s in writing, after all!), then let me show you a few examples of instructions gone very, very wrong.

没有标题的图片

这是 Jen Yates 的书Cake Wrecks(Andrews McMeel Publishing)的封面。(感谢 Jen 和 John Yates 提供这些。)这本书疯狂地从她那里冒出来娱乐网站cakewrecks.com。如果您没有至少一个小时可以浪费,请不要去那里。该网站展示了装饰奇特的蛋糕的照片,这些照片无法解释——但尽管如此,珍还是解释了它们。现在,网站和书中反复出现的主题之一是对需求的误解。但她当然不会将它们称为要求,因为这是一个书呆子般的词。她称它们为文字,因为读者阅读并逐字解释所写的内容。看着这些照片,我可以想象有人倾听顾客的声音,写下他想要的东西,然后将其交给装饰蛋糕的其他人。

This is the cover of Jen Yates’s book Cake Wrecks (Andrews McMeel Publishing). (Thanks to Jen and John Yates for supplying these.) The book sprang from her wildly entertaining website, cakewrecks.com. Please don’t go there if you don’t have at least an hour to waste. The site shows photos of oddly decorated cakes that defy explanation—but Jen explains them in spite of that. Now, one of the recurring themes in both the site and the book is misinterpreted requirements. But of course she doesn’t refer to them as requirements because it’s such a nerdy word. She calls them literals because the reader read and literally interpreted what was written. Looking at the photos, I can imagine someone listening to a customer and writing down what he wants, then handing that to someone else who’ll decorate a cake.

顾客:您好,我想订一个蛋糕。

雇员:当然可以,您想要在上面写什么?

顾客:你能用紫色写“再见,Alicia”吗?

员工:当然。

顾客:然后在它周围放上星星?

员工:没问题。我已经写好了,马上就交给我的蛋糕装饰师。我们会在早上为您准备好。

Customer: Hello, I’d like to order a cake.

Employee: Sure, what would you like written on it?

Customer: Could you write “So long, Alicia” in purple?

Employee: Sure.

Customer: And put stars around it?

Employee: No problem. I’ve written this up, and will hand it to my cake decorator right away. We’ll have it for you in the morning.

这是结果:

This is the result:

没有标题的图片

这是另一个。在软件开发中,我们称这些非功能性需求为:

Here’s another. In software development, we call these nonfunctional requirements:

没有标题的图片

这些都是有趣的例子,我们可以为在蛋糕上浪费 20 美元而发笑。但有时风险远不止于此。

These are funny examples, and we can laugh about wasting twenty bucks on a cake. But sometimes the stakes are much greater than that.

你可能听说过关于1999 年价值 1.25 亿美元的 NASA 火星气候轨道器坠毁。[ 1 ]好吧,也许你还没有。但这是妙语。如果有任何项目在需求和书面文档中引起了人们的注意,那么它就是 NASA 项目。然而,尽管所有文件柜都装满了要求和文件,但轨道飞行器还是坠毁了,因为虽然 NASA 使用公制进行测量,但洛克希德马丁公司工程团队的成员使用旧的英制测量系统为车辆的推进器开发导航命令。虽然没有人确切知道轨道飞行器最终去了哪里,但有些人认为它已经找到了它在火星以外某处绕太阳运行的快乐位置。

You’ve probably heard the story about the 1999 crash of a $125 million NASA Mars Climate Orbiter.[1] OK, maybe you haven’t. But here’s the punch line. If any project is sunk up to its eyeballs in requirements and written documentation, it’s a NASA project. However, despite all the filing cabinets full of requirements and documentation, the orbiter crashed because while NASA used the metric system for its measurements, members of the Lockheed Martin engineering team used the old imperial measurement system to develop navigation commands for the vehicle’s thrusters. While no one knows exactly where the orbiter ended up, some think it has found its happy place orbiting the sun somewhere past Mars.

具有讽刺意味的是,我们将内容写成书面形式以更清楚地沟通并避免误解的风险。但是,很多时候,情况恰恰相反。

Ironically, we put stuff in writing to communicate more clearly and to avoid risk of misunderstanding. But, way too often, the opposite is true.

共享文档不是共享理解。

Shared documents aren’t shared understanding.

停下来一分钟,把它写下来。把它写在便利贴上,然后放在口袋里。考虑把它纹在身上的某个地方,这样当你早上准备上班时就可以看到它。当你阅读它时,它会帮助你记住我现在给你讲的故事。

Stop for a minute and write that down. Write it on a sticky note and put it in your pocket. Consider getting it tattooed somewhere on your body so you can see it when you’re getting ready for work in the morning. When you read it, it’ll help you remember the stories I’m telling you now.

共享理解是指我们都了解对方的想法及其原因。显然,几个蛋糕装饰师和给他们书面指示的人之间没有共同的理解。而且,在 NASA,某个重要人物没有与其他从事制导系统工作的人分享理解。我敢肯定,如果您参与软件开发已有一段时间,您不必回想起过去的情况,两个人认为他们就想要添加到软件中的功能达成一致。软件,但后来发现人们想象的方式与其他人截然不同。

Shared understanding is when we both understand what the other person is imagining and why. Obviously, there wasn’t shared understanding between several cake decorators and the people who gave them instructions in writing. And, at NASA, someone important didn’t share understanding with others working on the guidance system. I’m sure if you’ve been involved in software development for a while, you don’t have to reach back far in your memory to recall a situation where two people believed they were in agreement on a feature they wanted to add to the software, but later found out that the way one imagined it was wildly different from the other.

建立共同理解非常简单

Building Shared Understanding Is Disruptively Simple

我的一位前同事 Luke Barrett 首先画了这幅漫画来描述这个问题。我问他第一次在哪里看到它,但他不记得了。所以外面的人没有得到他或她应得的荣誉。多年来,我看到卢克在 PowerPoint 幻灯片中逐步浏览这四个框架,而我却随意地认为它们很有趣但很明显。显然我的脑袋很厚。我花了很多年才明白这部卡通片是如何说明在软件开发中使用故事的最重要的事情。

A former coworker of mine, Luke Barrett, first drew this cartoon to describe this problem. I asked him where he first saw it, but he didn’t remember. So someone out there isn’t getting the credit he or she deserves. For years I saw Luke step through these four frames as slides in a PowerPoint deck while I casually dismissed them as interesting but obvious. Apparently I’ve got a thick head. It’s taken me many years to understand how this cartoon illustrates the most important thing about using stories in software development.

没有标题的图片

我的想法是,如果我在脑海中有一个想法并以书面形式描述它,那么当阅读该文档时,您很可能会想到一些不同的东西。我们甚至可以问每个人,“你们都同意那里写的吗?” 我们可能都会说,“是的!是的,我们有。”

The idea is that if I have an idea in my head and I describe it in writing, when you read that document, you might quite possibly imagine something different. We could even ask everyone, “Do you all agree with what’s written there?” and we might all say, “Yes! Yes, we do.”

但是,如果我们聚在一起谈谈,你可以告诉我你的想法,我可以提出问题。如果我们可以通过画图或使用索引卡或便利贴组织我们的想法来外化我们的想法,那么谈话会进行得更好。如果我们给彼此时间用文字和图片解释我们的想法,我们就会建立共同的理解。然而,正是在这一点上,我们意识到我们对事物的理解各不相同。太糟糕了。但至少现在我们知道了。

However, if we get together and talk, you can tell me what you think and I can ask questions. The talking goes better if we can externalize our thinking by drawing pictures or organizing our ideas using index cards or sticky notes. If we give each other time to explain our thoughts with words and pictures, we build shared understanding. It’s at this point, though, that we realize that we all understood things differently. That sucks. But at least now we know.

不是一个人的对错,而是我们看到的不同的重要方面。通过组合和提炼我们不同的想法,我们最终达成了一个包含我们所有最佳想法的共同理解。这就是为什么将我们的想法外化如此重要。我们可以重新绘制草图或四处移动便利贴,最酷的是我们真的在四处移动想法。我们真正在做的是发展我们的共同理解。光靠文字就太难了。

It’s not that one person is right or wrong, but that we all see different and important aspects. Through combining and refining our different ideas, we end up with a common understanding that includes all our best ideas. That’s why externalizing our ideas is so important. We can redraw sketches or move sticky notes around, and the cool thing is that we’re really moving ideas around. What we’re really doing is evolving our shared understanding. That’s super-hard with just words alone.

当我们离开这个对话时,我们可能仍然会提到相同的功能或增强功能,只是现在我们实际上指的是同一件事。我们感到一致并充满信心,我们正在共同前进。这就是我们要达到的质量。而且,可悲的是,它是无形的。您看不到或摸不到“共同理解”,但可以感觉到。

When we leave this conversation, we may still name the same feature or enhancement, it’s just that now we actually mean the same thing. We feel aligned and confident we’re moving forward together. That’s the quality we’re managing to. And, sadly, it’s intangible. You can’t see or touch “shared understanding,” but you can feel it.

停止尝试编写完美的文档

Stop Trying to Write Perfect Documents

有很多人相信有一些理想的记录方式——当人们阅读文档并得出不同的理解时,要么是读者的错,要么是文档作者的错。事实上,两者都不是。

There are a great number of people who believe that there’s some ideal way to document—that, when people read documents and come away with different understandings, it’s either the reader’s fault or the document writer’s. In reality, it’s neither.

答案就是阻止它。

The answer is just to stop it.

停止尝试编写完美的文档。

Stop trying to write the perfect document.

继续写点什么,任何东西。然后使用带有文字和图片的富有成效的对话来建立共同的理解。

Go ahead and write something, anything. Then use productive conversations with words and pictures to build shared understanding.

使用故事的真正目的是共享理解。

The real goal of using stories is shared understanding.

敏捷开发中的故事得名于它们应该如何使用,而不是你写下来的内容。如果您在开发中使用故事,而不是使用文字和图片进行交流,那您就错了。

Stories in Agile development get their name from how they should be used, not what you write down. If you’re using stories in development and you’re not talking together using words and pictures, you’re doing it wrong.

如果您阅读本书的目的是学习写出更好的故事,那您就错了。

If your goal in reading this book is to learn to write better stories, you’ve got the wrong goal.

好的文件就像度假照片

Good Documents Are Like Vacation Photos

如果我给你看我的假期之一照片,你可能会看到我的孩子们在海滩上并礼貌地说,“那很可爱,”但当我看我的假期照片时,我记得夏威夷的一个特定海滩,我们不得不在一个深深的车辙上行驶一个多小时 -轮驱动小径,然后再徒步半小时穿过熔岩区即可到达。我记得我的孩子们抱怨,说没有什么值得这样做,而我也在想同样的事情。但它是。我们在一个令人难以置信的海滩上度过了幸福的一天,那里人很少,这就是为什么我们不厌其烦地到达那里。海龟们来到岸边晒沙子,这为这美好的一天锦上添花。

If I show you one of my vacation photos, you might see my kids on a beach and politely say, “That’s cute,” but when I look at my vacation photo, I remember a particular beach in Hawaii that we had to drive more than an hour on a deeply rutted four-wheel-drive trail, and then hike another half-hour over lava fields to get to. I remember my kids whining, saying nothing could possibly be worth this, and me wondering the same thing. But it was. We enjoyed a blissful day on an incredible beach where very few people were, which is why we took the trouble to get there. The turtles came up on the shore to bask on the sand, which was the icing on the cake of this fabulous day.

没有标题的图片

当然,如果你看照片,你不会知道所有这些,因为你不在那里。我记得这一切,因为我是。

Of course, if you look at the picture you won’t know all that because you weren’t there. I remember all that because I was.

无论好坏,这就是文档实际工作的方式。

For better or worse, this is the way documents actually work.

如果你参与了很多关于要构建什么软件的讨论,然后创建一个文档来理解它,你可能会与在场的其他人分享它。你们可能都同意这很好。但请记住,您的共同理解是在填写文档中没有的详细信息。其他不在场的读者不会从中得到与您相同的东西。即使她说她明白了,也不要相信她。聚集在一起,使用文档来讲述一个故事,就像我用我的假期照片告诉你我的故事一样。

If you participate in lots of discussions about what software to build, and then create a document to make sense of it, you might share it with someone else who was there. You might both agree it’s good. But remember, your shared understanding is filling in details that aren’t in the document. Another reader who wasn’t there won’t get the same things from it that you will. Even if she says she gets it, don’t believe her. Get together and use the document to tell a story the same way I used my vacation photo to tell you my story.

帮助记忆的文件

Document to Help Remember

我听过有人开玩笑说,“我们正在使用敏捷过程,因为我们已经停止编写文档了。” 这对知道的人来说是个笑话,因为故事驱动的流程需要大量文档才能工作。但是这些文档并不总是看起来像传统的需求文档。

I’ve heard people joke, “We’re using an Agile process because we’ve stopped writing documents.” It’s a joke for people who know, because a story-driven process needs lots of documents to work. But those documents don’t always look at all like traditional requirements documents.

它需要谈话、素描、写作和使用便签或索引卡。它指向我们带入对话的文件,并用荧光笔和潦草的笔记标记它们。它具有互动性和高能量。如果您坐在会​​议桌旁,而一个人正在将您所说的话输入故事管理系统,那么您可能做错了。

It takes talking and sketching and writing and working with sticky notes or index cards. It’s pointing to documents we brought into the conversation and marking them up with highlighter and scribbled notes. It’s interactive and high energy. If you’re sitting at a conference table while a single person types what you say into a story management system, you’re probably doing it wrong.

当您讲故事时,几乎任何东西都可以用作交流的工具。当我们讲这些故事,写很多笔记,画很多图画时,我们需要保留它们。我们随身携带它们,以便稍后查看、拍照并重新输入更多文档。

When you’re telling stories, most anything can be used as a tool to communicate. And as we tell these stories, and write lots of notes, and draw lots of pictures, we need to keep them. We carry them around to look at later, photograph, and retype into more documents.

没有标题的图片

但是,请记住,最重要的不是写下来的内容——而是我们在阅读时记住的内容。这就是度假照片因素。

But, remember, what’s most important isn’t what’s written down—it’s what we remember when we read it. That’s the vacation photo factor.

交谈、素描、书写、使用便利贴和卡片,然后拍摄您的成果。更好的是,拍摄一段你在黑板上讨论内容的短片。你会记住很多你永远不可能记录下来的细节,而且非常深刻。

Talk, sketch, write, use sticky notes and cards, and then photograph your results. Even better, shoot a short video of you talking through what’s on the board. You’ll remember lots of details in a remarkable depth that you could never possibly document.

为帮助记忆,拍摄谈话结果的照片和短视频。

To help remember, photograph and shoot short videos of the results of your conversations.

谈论正确的事情

Talking About the Right Thing

有很多人认为他们的工作是收集和沟通要求。但事实并非如此。

There are lots of people who believe their job is collecting and communicating requirements. But it’s not.

事实上,你的工作是改变世界

The truth is, your job is to change the world.

是的,我这么说是为了引起你的注意。而且,是的,我知道这听起来有点夸张。那是因为这个短语通常与世界和平、消除贫困或什至更牵强的目标有关,比如让政客们达成共识。但我是认真的。你将每一个伟大的想法转化为产品解决方案,都会以某种小的或不太小的方式为使用它的人改变世界。事实上,如果没有,你就失败了。

Yes, I said that to get your attention. And, yes, I know that sounds like hyperbole. That’s because that phrase is usually associated with world peace, eliminating poverty, or even more far-fetched goals like getting politicians to agree with one another. But I’m serious. Every great idea you turn into a product solution changes the world in some small, or not-so-small, way for the people who use it. In fact, if it doesn’t, you’ve failed.

现在和以后

Now and Later

有一个简单的、改变世界的模型,我个人使用并一直牢记在心,当你进行故事对话和建立共同理解时,你也需要将它牢记在心。

There’s a simple, change-the-world model that I personally use and keep in my head all the time, and you need to keep it in your head too while you’re having story conversation and building shared understanding.

我画的模型是这样的:

I draw the model like this:

没有标题的图片

该模型从观察现在的世界开始。当你看世界现在的样子时,你会发现人们不快乐、疯狂、困惑或沮丧。现在,世界很大,所以我们将主要关注使用我们制作的软件的人,或者我们希望使用它的人。当您查看他们在做什么以及他们使用的工具和他们做事的方式时,您会想出点子,这些点子可能用于:

The model starts by looking at the world as it is now. When you look at the world as it is now, you’re going to find people who are unhappy, mad, confused, or frustrated. Now, the world’s a big place, so we’ll focus mostly on the people who use the software we make, or the people we hope will use it. When you take a look at what they’re doing—and the tools they use and how they’re doing things—you’re going to come up with ideas, and the ideas might be for:

  • 您可以构建的全新产品
  • Entirely new products you can build
  • 添加到现有产品的功能
  • Features to add to an existing product
  • 对您构建的产品的增强
  • Enhancements to products that you’ve built

在某个时间点,您必须与其他人交流有关您的想法的详细信息,并且您可能会开始进行一些设计和规范。如果您打算将所有这些交给其他人,那么您确实可以将所有这些细节称为您的要求但重要的是要记住,需求只是我们拥有的可以帮助人们的想法的别名。

At some point in time, you’ll have to communicate details about your ideas to some other people, and you might start to do some design and specification. If you’re going to hand all this off to someone else, then you might indeed call all these details your requirements. But it’s important to remember that requirements are just another name for the ideas we have that would help people.

鉴于这些要求,我们会经历一些导致交付的过程,然后产生一些实际登陆世界的软件,它会在以后登陆世界。我们希望的是,那些最初不开心、生气、沮丧或困惑的人会在该软件落地时变得快乐。现在,他们不高兴了,因为他们看到了它进来的那个漂亮的盒子——反正现在软件通常不装在盒子里了。他们不高兴,因为他们阅读了发行说明,或将应用程序下载到他们的移动设备上。他们很高兴,因为当他们使用软件、网站、移动应用程序或您构建的任何内容时,他们会以不同的方式做事——这就是让他们高兴的原因。

Given those requirements, we go through some process that results in a delivery, and out comes some software that actually lands in the world, and it lands in the world later. And what we hope is true is that those people who were initially unhappy, mad, frustrated, or confused will become happy when that software lands. Now, they’re not happy because they saw the pretty box it came in—software doesn’t usually come in boxes these days anyway. They’re not happy because they read the release notes, or downloaded the app to their mobile device. They’re happy because when they use the software, or the website, or the mobile app, or whatever you’ve built, they do things differently—and that’s what makes them happy.

现在,事实是你不能一直取悦所有人。你妈妈应该告诉你的。无论您生产什么,有些人都会比其他人更快乐,而有些人可能仍然不高兴,无论您工作多么努力,产品多么出色。

Now, the truth is that you can’t please everyone all of the time. Your mother should have told you that. Some people will be happier than others with whatever it is that you produce, and some might still be unhappy no matter how hard you’ve worked and how amazing your product might be.

软件不是重点

Software Isn’t the Point

想法和交付之间的一切都称为输出这就是我们建造的。从事敏捷软件开发的人们会刻意测量输出速度并尝试加快他们的输出速度。当人们构建软件时,他们当然会关心他们正在做的事情的成本以及他们应该做的事情完成的速度。

Everything between the idea and the delivery is called output. It’s what we build. People working in Agile software development will deliberately measure velocity of output and try to speed up their rate of output. As people are building software, they are, of course, concerned about the cost of what they’re doing and the speed at which what they’re doing gets done, as they should be.

但是,虽然这是必要的,但输出并不是真正的重点;这不是我们真正想要的输出。这就是随之而来的结果。这叫做结果。结果是事情发生时发生的事情——这就是为什么它被这样称呼——这很困难,因为在事情发生之前我们无法衡量结果。而且我们不会根据交付的功能数量或人们现在有能力做什么来衡量结果。我们衡量的是,由于您所构建的内容,人们为实现目标所做的实际不同,最重要的是,您是否让他们的生活变得更美好。[ 2 ]

But, while it’s necessary, the output isn’t the real point; it’s not the output that we really wanted. It’s what comes after as a result of that. It’s called outcome. Outcome is what happens when things come out—that’s why it’s called that—and it’s difficult because we don’t get to measure outcome until things do come out. And we don’t measure outcome by the number of features delivered, or what people have the capability to now do. We measure what people actually do differently to reach their goals as a consequence of what you’ve built, and most important, whether you’ve made their lives better.[2]

就是这样。你改变了世界。

That’s it. You’ve changed the world.

你在其中加入了一些东西,改变了人们实现目标的方式,当他们使用它时,世界对他们来说是不同的。

You’ve put something in it that changes the way people can reach their goals, and when they use it, the world is different for them.

如果您还记得的话,您的目标不仅仅是构建新产品或功能。当您就该功能进行对话时,您会谈论它是为谁服务的,他们现在做什么,以及以后的事情会如何改变。后来的积极变化才是他们想要它的真正原因。

If you remember, your goal isn’t to just build a new product or feature. When you have conversations about that feature, you’ll talk about who it’s for, what they do now, and how things will change for them later. That positive change later is really why they’d want it.

好的故事对话是关于谁和为什么,而不仅仅是什么。

Good story conversations are about who and why, not just what.

好的,这不仅仅是关于人

OK, It’s Not Just About People

我和下一个人一样关心别人,但说实话,这不仅仅是让人们开心。如果你为一家为你和其他人支付报酬的公司工作,你必须关注最终帮助你的组织赚取更多收入、保护或扩大其市场或更有效运营的因素。因为,如果您的公司不健康,那么您将没有资源(或工作)来帮助任何人。

I care about people as much as the next guy, but truthfully, it’s not just about making people happy. If you work for a company that pays you and others, you’ve got to focus on what ultimately helps your organization earn more, protect or expand its market, or operate more efficiently. Because, if your company isn’t healthy, then you won’t have the resources (or the job) to help anyone.

所以我必须稍微修改一下这个模型。它实际上是从审视您的组织内部开始的。在那里你会发现更多不快乐的人。这通常是因为业务表现不如他们希望的那样。为了解决这个问题,他们可能有想法关注特定的客户或用户,并制作或改进他们正在使用的软件产品。你看,它最终是关于人的,因为:

So I’ve got to revise this model a bit. It actually starts by looking inside your organization. There you’ll find even more people who aren’t happy. And it’s usually because the business isn’t performing as well as they’d hope. To fix this, they may have ideas to focus on specific customers or users and to make or improve the software products they’re using. You see, it ultimately is about people, because:

除非您的客户和用户得到他们想要的东西,否则您的公司无法得到它想要的东西。

Your company can’t get what it wants unless your customers and users get something they want.

通过选择要关注的人、要解决的问题以及将想法转化为工作软件,流程继续进行。从那里开始——如果客户购买,用户使用它,人们感到高兴——最终赞助这一开发的企业将看到它正在寻找的好处。这将反映在收入增加、运营成本降低、客户更满意或市场份额扩大等方面。这让贵公司内部的很多人都很高兴。它也应该让你快乐,因为你刚刚帮助你的公司保持健康,同时在这个过程中让人们的生活变得更好。这是双赢的。

The flow continues by choosing the people to focus on, the problems to solve, and the ideas to turn into working software. And from there—if the customers buy, and the users use it, and people are happy—eventually the business that sponsored this development will see the benefit it’s looking for. That’ll be reflected in things like increased revenue, lower operational costs, happier customers, or expanded market share. This makes lots of people inside your company happy. It should make you happy, too, since you’ve just helped your company stay healthy while making real people’s lives better in the process. It’s a win-win.

没有标题的图片

这是由于良好结果而发生的长期事情,我将其标记为影响结果通常是您可以在分娩后立即观察到的。但影响需要更长的时间。

It’s that longer-term stuff that happens as a consequence of good outcomes that’s I’ll label impact. Outcomes are often something you can observe right away after delivery. But impact takes longer.

少建

Build Less

软件世界有一个令人不安的事实,我怀疑很多其他地方也是如此。但我懂软件。我所知道的是:

There’s an uncomfortable truth about the software world, and I suspect it’s true of lots of other places. But I know software. And what I know is that:

总是有比我们有时间或资源要构建的更多的东西——总是如此。

There’s always more to build than we have time or resources to build—always.

软件开发中的一个常见误解是我们试图更快地获得更多输出。因为如果有太多事情要做,那么做得更快会有所帮助,对吧?但如果你玩对了游戏,你就会意识到你的工作不是建造更多——而是建造更少

One of the common misconceptions in software development is that we’re trying to get more output faster. Because it would make sense that if there was too much to do, doing it faster would help, right? But if you get the game right, you will realize that your job is not to build more—it’s to build less.

最小化输出,最大化结果和影响。

Minimize output, and maximize outcome and impact.

归根结底,您的工作是最大限度地减少产出,并最大限度地提高成果和影响。诀窍在于你必须密切关注那些你正在努力解决其问题的人。这些包括将选择购买软件来解决其组织中的问题的人、选择者,以及使用它的人、用户。有时他们是同一个人。有时他们不是。

At the end of the day, your job is to minimize output, and maximize outcome and impact. The trick is that you’ve got to pay close attention to the people whose problems you’re trying to solve. These include the people who will choose to buy the software to solve a problem in their organizations, the choosers, as well as the people who use it, the users. Sometimes they’re the same people. Sometimes they’re not.

没有标题的图片

您的企业有很多可以关注的潜在用户和客户。您的业​​务战略应该为您提供一些指导,让您了解应该关注哪些人才能获得您想要的影响。我向你保证,没有一家企业拥有让每个人都开心的资源——这是不可能的。

Your business has lots of possible users and customers it could focus on. Your businesses strategy should give you some guidance about who to focus on to get the impact you want. I promise you that no business has the resources to make everyone happy—it’s just not possible.

别误会我的意思。更快地构建更多软件总是一个好主意。但这永远不是解决方案。

Don’t get me wrong here. Building more software faster is always a good idea. But it’s never the solution.

更多关于可怕的“R”字

More on the Dreaded “R” Word

在我软件职业生涯的几乎整个头十年,我都在为实体零售商构建软件,我没有使用需求这个词——至少,没有太多。这不是我正在做的事情的相关术语。我有很多不同的客户,他们对什么可以帮助他们都有具体的想法。我也知道我在一家必须通过销售我的产品来赚钱的公司工作。事实上,我在贸易展上花了很长时间,帮助我的公司向各种各样的客户销售产品。最终,我知道在我和我的团队开发的产品交付后,我必须继续与这些客户合作,因此我努力工作,为他们的最大利益服务。这意味着我不能给每个人他们想要的一切,因为他们想要不同的东西。我的公司和团队没有无限的时间,所以我必须努力工作,找出我能做的最少的事情来让人们开心。这听起来可能令人沮丧,但这实际上是有趣的部分。

For almost the entire first decade of my software career, which I spent building software for brick-and-mortar retailers, I got away without using the word requirements—at least, not much. It just wasn’t a relevant term for what I was doing. I had lots of different customers who all had specific ideas about what would help them. I also knew I worked for a company that had to make money by selling my product. In fact, I’d spent long hours standing at trade shows helping my company sell its product to a wide variety of customers. I knew at the end of the day that I would have to continue to work with those customers after I shipped the products my team and I developed, and so I diligently worked to act in their best interest. This meant I couldn’t give everyone everything they wanted, because they wanted different things. And my company and team didn’t have infinite time, so I had to work hard to figure out the least I could build to make people happy. That may sound frustrating, but it’s actually the fun part.

随着公司的发展,我们增加了更多的传统软件人员。有一次,另一个团队的负责人来找我说,“杰夫,我需要你对你正在开发的产品进行这些更改。”

As the company grew, we added more traditional software people. At one point, the head of a different team came to me and said, “Jeff, I need you to make these changes to the product you’re working on.”

我说:“很好,没问题。告诉我他们是为谁服务的,这为他们解决了哪些问题。”

I said, “Great, no problem. Tell me who they’re for and what problems this solves for them.”

她的回应?“他们是要求。”

Her response? “They’re the requirements.”

我回答说:“我明白了。只需告诉我一些关于他们是为谁服务的,他们将如何使用它,以及它适合他们工作方式的哪些地方。”

I replied, “I get it. Just tell me a bit about who they’re for, and how they’re going to use this, and where it fits into the way they work.”

她看着我,就像我是个傻子一样,最后一次对我说,“他们是要求。”

She looked at me like I was stupid and said to me one last time with an air of finality, “They’re requirements.”

那一刻我才知道要求这个词其实就是闭嘴的意思。

It was at that moment that I learned that the word requirements actually means shut up.

对于很多人来说,这正是需求的作用。他们停止谈论人和我们正在解决的问题。事实是,如果你构建的只是所需内容的一小部分,你仍然可以让人们非常开心。[ 3 ]

For a great many people, that’s exactly what requirements do. They stop conversations about people and the problems we’re solving. The truth is, if you build a fraction of what’s required you can still make people very happy.[3]

记住:归根结底,你的工作不是满足需求——你的工作是改变世界。

Remember: at the end of the day, your job isn’t to get the requirements right—your job is to change the world.

这里的所有都是它的

That’s All There Is to It

如果您从本书中没有得到任何其他信息,请记住以下几点:

If you get nothing else from this book, remember these things:

  • 故事不是需求的书面形式;通过文字和图片的协作讲故事是一种建立共同理解的机制。
  • Stories aren’t a written form of requirements; telling stories through collaboration with words and pictures is a mechanism that builds shared understanding.
  • 故事不是必需的;他们正在讨论为我们的组织、我们的客户和我们的用户解决问题,从而就构建内容达成一致。
  • Stories aren’t the requirements; they’re discussions about solving problems for our organization, our customers, and our users that lead to agreements on what to build.
  • 你的工作不是更快地构建更多软件:它是最大化你从你选择构建的东西中获得的结果和影响。
  • Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build.

故事的本意是以一种完全不同的方式来思考我们共同创造软件所面临的挑战——以及许多其他事情,就此而言。如果你们能有效地合作并创造解决问题的东西,你们将统治世界。或者至少其中的一小部分被您的产品所占据。

Stories as they’re intended are a completely different way of thinking about the challenges we face working together to create software—and lots of other things, for that matter. If you can work together effectively and create things that solve problems, you will rule the world. Or at least some small part of it inhabited by your products.

当您阅读本书时,我希望您能回到使用故事的基础知识。我希望您与其他人一起工作,讲述您的用户和客户的故事,以及您可以如何帮助他们。我希望你画画,并制作大型便签纸模型。我希望你感到参与和创造性。我希望你觉得你正在有所作为。因为当你做对的时候,你就是。而且它也更有趣。

As you read this book, my hope is that you get back to the basics of using stories. I hope you work together with others, telling stories about your users and customers and how you can help them. I hope you draw pictures, and build big sticky-note models. I hope you feel engaged and creative. I hope you feel like you’re making a difference. Because when you do it right, you are. And it’s a lot more fun, too.

现在是时候谈谈讲故事可能带来的最大乐趣了,那就是您使用故事地图的时候。

Now it’s time to talk about the most fun you can possibly have telling stories, and that’s when you’re using a story map.




[ 1 ]有很多文章试图描述火星轨道器出了什么问题。这是其中之一:http ://www.cnn.com/TECH/space/9909/30/mars.metric.02/ 。

[1] There are a lot of articles that try to describe what went wrong with the Mars Orbiter. Here’s one of them: http://www.cnn.com/TECH/space/9909/30/mars.metric.02/.

[ 2 ]在罗伯特·法布里坎特 (Robert Fabricant) 的一次名为“行为是我们的媒介”的演讲中,我首先清楚地了解了简洁的语言以及输出结果之间的区别。在此之前,我一直在为脑海中清晰的语言而苦苦挣扎——其他人也是如此。令人高兴的是,罗伯特的头脑很清楚。

[2] The clean language and distinction between output and outcome was first made clear to me in a talk by Robert Fabricant called “Behavior Is Our Medium”. Prior to that, I’d struggled with language that was clear in my head—and everyone else’s too. Happily, it was clear in Robert’s head.

[ 3 ]因为我非常同意这种观点,所以我转述了 Kent Beck 在他的《Extreme Programming Explained 》 (Addison-Wesley)一书中警告不要滥用术语需求的方式。

[3] Because I strongly agree with the sentiment, I’m paraphrasing the way Kent Beck cautions against the misuse of the term requirement in his book Extreme Programming Explained (Addison-Wesley).

第 1 章大局

Chapter 1. The Big Picture

“我喜欢敏捷开发!每隔几周我们就会看到更多可用的软件。但感觉就像我失去了大局。”

“I love Agile development! Every few weeks we see more working software. But it feels like I’ve lost the big picture.”

如果我每次从敏捷团队成员那里听到类似的话都能得到一毛钱,那么我会有……好吧……很多毛钱。我经常听到。你甚至可能自己也说过类似的话。好吧,我有好消息要告诉你。使用敏捷流程和故事驱动的方法并不意味着您必须牺牲大局。你仍然可以对你的整个产品进行健康的讨论,并且仍然每隔几周就能看到进展。

If I had a dime for every time I heard something like that from an Agile team member, I’d have…well…a lot of dimes. I hear it a lot. You may have even said something like that yourself. Well, I’ve got good news for you. Using an Agile process and a story-driven approach doesn’t mean you have to sacrifice the big picture. You can still have healthy discussions about your whole product and still see progress every few weeks.

由于您已经耐心地阅读了“首先阅读本章”一章,我将绕过所有关于故事的垃圾内容,直接进入故事地图如何解决敏捷开发中最大的问题之一。如果您已经熟悉编写有关敏捷项目的故事,那么本章可能足以让您入门。

Since you’ve patiently read the “Read This First” chapter, I’m going to bypass all the junk about stories and proceed directly to how story maps solve one of the biggest problems in Agile development. If you’re already familiar with writing stories on Agile projects, this chapter may be enough to get you started.

“A”字

The “A” Word

如果您正在阅读本书,您可能知道故事映射是一种处理用户故事的方法,因为它们被用于敏捷流程。现在,正是在这一点上,所有其他与敏捷开发有关的书都在重现“敏捷软件开发宣言”,那是 2001 年由 17 个人写的东西,他们对正在发生的一些适得其反的大过程趋势感到沮丧时间。我很高兴他们写了它。我很高兴许多人都感受到了他们工作的影响。

If you’re reading this book, you likely know that story mapping is a way to work with user stories as they’re used in Agile processes. Now, it’s at this point that every other book that has something to do with Agile development reproduces the “Manifesto for Agile Software Development,” that thing written in 2001 by 17 guys who were frustrated with some of the big counterproductive process trends going on at the time. I’m glad they wrote it. And I’m glad that the impact of their work has been felt by so many.

但很抱歉让你失望了——我不会重印宣言并滔滔不绝地谈论它的重要性。我相信你已经知道为什么会这样。而且,如果您还没有阅读宣言,那么您应该阅读。

But I’m sorry to disappoint you—I’m not going to reprint the manifesto and gush about why it matters. I believe you already know why it does. And, if you haven’t read the manifesto, then you should.

在宣言本应在本章中占据的空间中,我加入了一张有趣的小猫照片。[ 4 ]为什么?因为一次又一次地证明,有趣的小猫照片在互联网上获得的关注远远超过任何宣言所希望的。

In the space that the manifesto would have taken up in this chapter, I am instead including a funny kitten photo.[4] Why? Because it has been proven time and time again that funny kitten photos on the Internet get far more attention than any manifesto could ever hope to.

没有标题的图片

那么,您可能想知道,这只小猫与敏捷有什么关系?其实,没什么。但敏捷肯定与这本书有关,与故事和故事映射的演变有关。

So, you might wonder, what does this kitten have to do with Agile? Actually, nothing. But Agile definitely has something to do with this book, and with stories and the evolution of story mapping.

<提示闪回音乐……>

<Cue the flashback music…>

2000 年,我在旧金山的一家初创公司工作,该公司聘请了Kent Beck(创建极限编程并首先描述故事概念的人)作为顾问让软件开发过程继续进行。我倒回去了,但重要的是这个故事的想法是一个古老的想法。如果您刚刚开始使用故事,那么您将失去十年前可能拥有的任何早期采用者身份。Kent 和其他开创了极限编程的人都知道,过去所有这些处理需求的方法都不太奏效。肯特的简单想法是我们应该聚在一起讲述我们的故事;通过交谈,我们可以建立共同的理解,并共同达成更好的解决方案。

I was working at a startup in San Francisco in 2000, and the company had hired Kent Beck (the guy who created Extreme Programming and first described the idea of stories) as a consultant to get the software development process going. I’m rewinding way back, but the important thing is this story idea is an old one. If you’re just starting out with using stories, you lost any early adopter status you could have had a decade or so ago. Kent and others who pioneered Extreme Programming knew that all those ways of doing requirements in the past didn’t work out well. Kent’s simple idea was that we should get together and tell our stories; that by talking we could build shared understanding, and together we’d arrive at better solutions.

讲故事,而不是写故事

Telling Stories, Not Writing Stories

当我第一次听到故事这个词时,它让我感到困扰。我会承认的。我们通过将人们想要的重要事物称为故事来贬低它们的想法似乎并不正确。但我学得慢——这是我之前在讨论共享理解时提出的一点。我花了一段时间才真正明白:

When I first heard the term story, it bugged me. I’ll admit it. The idea that we’d trivialize the important things that people wanted by calling them stories didn’t seem right. But I’m a slow learner—a point I brought up earlier when discussing shared understanding. It took me a while to really get that:

故事得名于它们应该如何使用,而不是应该写什么。

Stories get their name from how they should be used, not what should be written.

甚至在我真正理解为什么故事有这个名字之前,我就意识到我可以在便利贴或卡片上写下一堆故事——一句话或一个简短的标题。我可以四处移动它们并确定它们的优先级,以决定哪个更重要。一旦我确定一个比另一个更重要,我们就可以开始讨论它。这太酷了。为什么我以前从来没有在卡片上写过东西并以这种方式组织它们?

Even before I’d really understood why stories had that name, I realized that I could write down a bunch of stories—a sentence or a short title—on sticky notes or cards. I could move them around and prioritize them to decide which one was more important. Once I decided that one was more important than another, then we could start having a discussion about it. This was super-cool. Why hadn’t I ever written things on cards and organized them this way before?

问题是这张卡片可能只需要软件开发人员几个小时就可以添加到产品中,或者可能需要几天或几周,或者一个月——谁知道呢?我没有——至少在我们开始谈论它之前没有。

The problem was that this one card could be something that might take a software developer just a couple hours to add to a product, or maybe a couple days or a couple weeks, or maybe a month—who knew? I didn’t—at least not until we started talking about it.

当我开始故事对话并了解到我的故事太大时,我在处理我的第一个敏捷项目的故事时陷入了激烈的争论。我希望在下一次迭代中完成这个故事。与我交谈的开发人员告诉我情况并非如此。我觉得我做错了什么。开发人员确定了我们可以讨论的一小部分,可以在我们的下一次迭代中完成。但我很沮丧,因为我们不能谈论大局。我真的很想了解我真正需要的大事需要多少时间。我希望这次讨论能够实现这一点,但它没有。

I got into a nasty argument while working with stories on my very first Agile project when I began a story conversation and learned that my story was too big. I’d hoped to get this story done in the next iteration. The developers I spoke with informed me otherwise. I felt like I’d done something wrong. The developers identified a small part we could talk about that could be accomplished in our next iteration. But I left frustrated that we couldn’t talk about the big picture. I really wanted to understand how much time the big thing I really needed would take. I’d hoped this discussion would accomplish that, and it didn’t.

讲述整个故事

Telling the Whole Story

2001 年,我离开了我所在的团队,开始以不同的方式做事。我和我的团队尝试了一种着眼于大局的故事写作方法。我们努力了解我们正在构建的产品并共同做出权衡。我们使用那一堆带有故事标题的索引卡来组织我们的想法,并将大图分解成我们接下来可以构建的小部分。2004 年,我写了第一篇关于这个想法的文章。然而,直到 2007 年,我才创造出故事地图这个词。

In 2001 I left the team I was on and started doing things differently. I, and my team, tried an approach to writing stories that focused on the big picture. We worked to understand the product we were building and to make tradeoffs together. We used that bunch of index cards with story titles to organize our thoughts and break down that big picture into the small parts we could build next. In 2004, I wrote my first article about this idea. I didn’t coin the term story mapping, however, until 2007.

事实证明,你给某物起的名字很重要。正是在给这种做法起了好名字之后,我才真正看到它传播开来。当时我认为这是一项伟大的发明——也就是说,直到我开始遇到更多的人在做类似的事情,如果不是完全相同的话。我发现了一个规律

It turns out that the name you give something matters. It was after giving the practice a good name that I really saw it spread. I thought it was a great invention at the time—that is, until I started running into more people who were doing similar if not exactly the same things. I’d discovered a pattern.

我第一次从我的朋友 Linda Rising 那里听到模式的这个定义:当你告诉某人一个好主意,他说,“是的,我们也做类似的事情。” 这不是发明,这是一种模式。

I first heard this definition of a pattern from my friend Linda Rising: when you tell someone about a great idea and he says, “Yeah, we do something like that, too.” It’s not an invention, it’s a pattern.

故事映射是一种模式。这是明智的人为了理解整个产品或整个功能所做的事情。这是他们将大故事分解成小故事的方法。如果您没有自己到达目的地,请不要感到难过。你最终会的。但是阅读这本书会让你避免数周或数月的挫败感。

Story mapping is a pattern. It’s what sensible people do to make sense of a whole product or whole feature. It’s what they do to break down large stories into smaller ones. Don’t feel bad if you didn’t arrive at it on your own. You would have eventually. But reading this book will save you weeks or months of frustration.

故事地图用于分解您讲述的大故事。

Story maps are for breaking down big stories as you tell them.

如今,一家又一家公司采用了故事地图的理念。我在 SAP 的朋友 Martina 在 2013 年 9 月发送的消息中说:

Today, company after company has adopted the idea of story mapping. My friend Martina at SAP said in a message she sent in September 2013 that:

……此时已经正式记录了 120 多个 USM [用户故事映射] 研讨会。很多 PO 只是简单地喜欢它!这只是 SAP 行之有效的方法。

…at this point more than 120 USM [User Story Mapping] workshops have officially been recorded. A lot of POs just simply love it! It is simply a well-established approach at SAP.

每周我都会听到来自其他地方的其他人告诉我绘图故事如何帮助他们解决问题。这些天来,我从与他人交谈中学到的东西比我自己学到的要多。

Every week I hear from someone else from somewhere else telling me how mapping stories helped solve a problem for them. These days, I learn more from talking to others than I ever could on my own.

故事的最初想法很简单。它使我们的注意力从共享文档转向共享理解。使用故事的一种常见方法是建立一个故事列表,确定它们的优先级,然后开始谈论它们,然后将它们一次一个地转化为软件。当你听到它时,这听起来很合理。但它会产生一些大问题。

The original idea of stories was a simple one. It turned our focus away from shared documents and toward shared understanding. A common way to use stories is to build a list of them, prioritize them, and begin talking about them and then turning them into software one at a time. That sounds pretty reasonable when you hear about it. But it can create some big problems.

加里和平面积压的悲剧

Gary and the Tragedy of the Flat Backlog

几年前我遇到了加里莱维特。加里是一名正在推出新网络产品的商人。网络产品现在就在那里,它被称为 Mad Mimi,当 Gary 构思他的产品时,它是音乐行业营销界面的缩写。[ 5 ]加里是一位拥有自己乐队的音乐家。他管理自己的乐队,帮助管理其他乐队,同时也是一名录音室音乐家,为客户创作唱片。

A few years ago I met Gary Levitt. Gary was a businessperson in the process of launching a new web product. The web product is out there right now, and it’s called Mad Mimi, which when Gary conceived of his product, was short for music industry marketing interface.[5] Gary is a musician who had his own band. He managed his band, helped manage others, and was also a studio musician and created recordings for clients.

没有标题的图片

我遇见加里的那天,他接到了奥普拉·温弗瑞 (Oprah Winfrey) 节目的订单,需要几十个前奏和结尾,以及一些用于广告和类似内容的音乐片段。电视节目的制作人购买它们的方式就像排版时事通讯的人购买剪贴画一样,所以它就像音频剪贴画一样。加里有一个相当大的应用程序的想法,可以帮助像他这样的音乐家和他认识的人在他正在从事的项目中相互合作,以及乐队经理和音乐家需要做的许多其他事情管理和推广他的乐队。

The day I met Gary he had an order from the Oprah Winfrey show for dozens of intros and outros, little bits of music that are used to go out to and come in from commercials and things like that. Producers of television shows buy those the way people laying out a newsletter buy clip art, so it’s like audio clip art. Gary had an idea for a fairly big application that would help musicians like him and people he knew to collaborate with one another on projects like the one he was working on, along with lots of other things a band manager and musician would need to do to manage and promote his band.

Gary 想要构建软件,所以他和某人一起工作,而那个人正在以敏捷的方式工作。那个人告诉加里写下他想要的所有东西的清单,对清单进行优先排序,然后他们会讨论价值最高的东西——最重要的东西——然后开始逐一构建它们。这份清单就是敏捷流程所称的待办事项列表,Gary 创建清单并首先从最重要的事情开始似乎是有意义的。所以这就是他所做的。

Gary wanted to get the software built so he worked with somebody, and that somebody was working in an Agile way. That person told Gary to write down a list of all the things he wanted, prioritize the list, and then they would talk about the highest-valued things—the most important—and start building them one at a time. That list of things is what Agile processes refer to as a backlog, and it seemed to make sense to Gary to create the list and start with the most important things first. So that’s what he did.

加里创建了他的积压工作,开发团队开始一次构建一些东西。与此同时,加里继续为每一个构建的软件支付费用,导致现金流失。该软件正在慢慢成型,但加里可以看出,它需要更长的时间才能符合他的设想,而且他很早就会用完现金。

Gary created his backlog and the development team started building things a bit at a time. In the meantime, Gary was hemorrhaging cash as he continued to pay for each piece of software that was built. The software was slowly taking shape, but Gary could tell it was going to take a lot longer for it to match his vision and he was going to run out of cash long before then.

我认识和加里一起工作的人。我的朋友知道加里压力很大,想帮助他。我认识的人问我是否可以与加里交谈,与他交谈并帮助他组织他的想法。我联系了加里并安排在他位于曼哈顿的办公室与他会面。

I knew the person who was working with Gary. My friend knew Gary was stressing out and wanted to help him. The somebody I knew asked if I could have a conversation with Gary, to talk with him and help him get his ideas organized. I contacted Gary and made arrangements to meet him at his office in Manhattan.

谈话和文件

Talk and Doc

加里和我开始交谈。在他说话的同时,我根据他所说的要点写了卡片。在构建故事地图时,我喜欢一句口头禅。我会说“talk and doc”(动词文档的缩写),这基本上意味着不要让你的话蒸发。将它们写在卡片上,以便您以后可以参考。你会注意到指向卡片上的几个词如何快速帮助每个人回忆起关于它的对话。我们可以在桌子周围滑动它们,在那里我们可以重新组织它们。当我们指向卡片时,我们开始使用这样那样有用词。它可以节省很多时间。帮助加里具体化他的想法对于获得共同理解至关重要。这对他来说不是一个习惯,所以我很容易在他讲故事的时候写卡片。

Gary and I started talking. And as he talked, I wrote cards with key points from what he said. There’s a mantra that I like when I build story maps. I’ll say “talk and doc” (short for the verb document), which basically means don’t let your words vaporize. Write them down on cards so you can refer back to them later. You’ll notice how pointing to a few words on a card quickly helps everyone recall the conversation about it. We can slide them around the table where we can reorganize them. We start using useful words like this and that as we point to cards. It saves lots of time. Helping Gary externalize his thoughts was critical to getting shared understanding. It wasn’t a habit for him, so it was easy for me to write the cards as he told the story.

谈话和记录:写卡片或便利贴,在讲故事时将您的想法具体化。

Talk and doc: write cards or sticky notes to externalize your thinking as you tell stories.

我们首先将卡片放在桌面上,但很快就用完了。我拜访他的那天,加里正在搬办公室,他所在的纽约市阁楼里的大部分家具都在地板上。因此,我们将不断增长的卡片地图移到了地板上。

We started by placing cards on a tabletop, but quickly ran out of space. Gary was moving offices the day I visited with him, and much of the furniture in the New York City loft where he was located was off the floor. So we moved our growing map of cards onto the floor.

在一天结束时,地板看起来像这样:

At the end of the day, the floor looked like this:

没有标题的图片

我不是来这里了解 Gary 的要求的。我们谈论的第一件事不是功能列表。我们不得不后退一点,从头开始。

I wasn’t here to capture Gary’s requirements. And the first thing we talked about wasn’t that list of features. We had to back up a bit and start at the beginning.

构建您的想法

Frame Your Idea

我们的第一次谈话集中在构建他的产品理念上。我们谈论了他的生意和他的目标。你为什么要建这个?告诉我对您和使用它的人的好处。它为那些人和你解决了什么问题?当您阅读本文时,您可能会发现我脑子里已经有了那个现在和以后的模型。我试图了解 Gary 正在寻找的结果,而不是他想要构建的输出。

Our first conversation focused on framing his product idea. We talked about his business and what his goals were. Why are you building this? Tell me about the benefits for you and for the people who will use this. What problems does it solve for those people and for you? As you read this you might detect I’ve got that now-and-later model in my head. I’m trying to understand the outcomes Gary is looking for, not the output he wants to build.

如果我放下两张牌,一张放在另一张上面,那么人们就会认为上面的一张更重要。一言不发,如果我只是把一张卡片滑到另一张上面,我已经指出了一些重要的事情。尝试使用目标列表。故意将它们按错误的顺序排列,然后看着与您一起工作的人伸出手来调整它们。我对加里和他的目标做了这个,这帮助他表达了对他来说更重要的东西。

If I put two cards down, one above the other, then people assume that the one above is more important. Without saying a word, if I simply slide a card above another, I’ve indicated something about importance. Try that with a list of goals. Purposely put them in the wrong order and watch the person you’re working with reach out to adjust them. I did this with Gary and his goals, and it helped him express what was more important to him.

没有标题的图片

描述您的客户和用户

Describe Your Customers and Users

加里和我继续交谈和记录。加里和我的下一次谈话是关于购买他的软件的客户和使用他的软件的用户。我们列出了不同类型的用户。我们讨论了他们会得到什么好处,并询问他们为什么要使用该产品以及我们认为他们会用它做什么。这对他们有什么好处?我们建造了一大堆。这些卡片似乎自然而然地落在一堆最重要的用户身上。有趣的是,它是如何在没有明确决定的情况下以这种方式运作的。

Gary and I continued to talk and doc. The next conversation Gary and I had was about the customers who would buy, and users who would use, his piece of software. We listed the different types of users. We talked about what benefits they would get, and asked why they would use the product and what we thought they would do with it. What was in it for them? We built a big pile of those. The cards naturally seemed to fall with most important users higher in the pile. Funny how it works out that way without an explicit decision.

没有标题的图片

在我们讨论任何细节之前,我已经看出 Gary 的远见卓识。软件开发的一个严峻现实是,要构建的东西总是超出我们的时间和金钱。因此,目标永远不应该是全部构建。目标是尽量减少我们建造的数量。所以我问加里的第一个问题是,“在所有这些不同的用户和他们想做的事情中,如果我们只专注于让其中一个用户兴奋,那会是谁?”

Before we’d gone into any detail at all, I could already see that Gary’s vision was big. One of the tough realities about software development is that there’s always more to build than we have time and money for. So the goal should never be to build it all. The goal is to minimize the amount we build. So the first question I asked Gary was, “Of all these different users and the things they want to do, if we were to focus on thrilling just one of those users, who would it be?”

加里选择了一个,我们开始真正讲故事。

Gary chose one and we started to really tell stories.

讲述用户的故事

Tell Your Users’ Stories

接下来我说,“好吧,让我们想象一下未来。让我们暂时假设这个产品是实时的,让我们谈谈使用它的人生活中的一天并开始讲述这个故事。首先,他们会做这个,然后做这个,依此类推。” 我们从左到右依次讲述这个故事。有时我们回溯并将一些东西放在其他东西的左边,因为它们在卡片上,我们可以很容易地重新排列它们。

I next said, “OK, let’s imagine the future. Let’s assume for a minute this product is live and let’s talk about a day in the life of someone who uses it and start telling the story. First, they would do this, and then this, and so on and so on.” And we told the story in a flow from left to right. Sometimes we backtracked and put things to the left of other things, and because they were on cards, we could easily rearrange them.

使用卡片时自然会发生的另一件有趣的事情是,如果我把一张放在左边,另一张放在右边,我一言不发,我已经指出了顺序。这对我来说有点神奇——但我很容易被娱乐。我惊叹于我们可以不言而喻地交流多少。

The other interesting thing that happens naturally when working with cards is if I put one to the left and another to the right, without saying a word I’ve indicated sequence. This is kind of magical for me—but I’m easily entertained. I marvel at how much we can communicate without saying a word.

将卡片重新整理在一起可以让您无需说一句话即可进行交流。

Reorganizing cards together allows you to communicate without saying a word.

当我们交谈和记录时,以及当我写下我们的谈话时,我们正在构建一些非常重要的东西。不,不是地板上那一堆卡片。真正重要的是共同理解。我们正在达成共识。这是 Gary 以前从未与任何人就他的产品创意做过的事情,至少在这种细节级别上没有。他自己从来没有想过这么多。高潮在他的脑海里,有点像你在电影预览中看到的动作场面。

As we talk and doc, and as I write down our conversation, we’re building something really important. No, it’s not that pile of cards on the floor. The something that’s really important is shared understanding. We’re getting on the same page. This is something Gary had never done with anyone before about his product idea, at least not at this level of detail. He’d never even given it this much thought himself. The high points were in his head, sort of like the action scenes you’d see in a movie preview.

在此之前,加里已经完成了他被要求做的事情。他写了一堆故事标题,把它们列在一张清单上,然后一次一个地谈论它们。谈话更多的是关于构建什么的细节,而不是大局。加里的大局中有很多漏洞。你会发现,无论你对你的故事有多清楚,在你绘制地图的时候通过它来谈论它会帮助你发现你自己思维中的漏洞。

Before now, Gary had done what he was asked to do. He’d written a bunch of story titles, put them in a list, and talked about them one at a time. The conversations were more about the details of what to build and less about this big picture. And there were a lot of holes in Gary’s big picture. You’ll find that no matter how clear you are about your story, talking through it while you map will help you discover the holes in your own thinking.

映射您的故事可以帮助您找到思维中的漏洞。

Mapping your story helps you find holes in your thinking.

随着我们深入挖掘,我们意识到这个故事也不只是关于一个用户。加里 (Gary) 从一位乐队经理开始,他想宣传他的乐队以及他正在做的工作,以创建宣传并将其通过电子邮件发送给粉丝。然后我们很快不得不谈论乐队的粉丝,并讲述她看到宣传然后计划去看演出的故事。

As we dug deeper, we realized that the story also wasn’t just about one user. Gary’s started with a band manager who wanted to promote his band and the work he was doing to create the promotion and email it to fans. Then we quickly had to talk about the fan of the band, and tell her story about seeing the promotion and then making plans to see a show.

然后,如果我们在某个地方宣传乐队,我们需要讲述场地经理的故事以及他想了解有关宣传的信息。到这个时候,我们的地图已经足够宽了,以至于我们撞到了墙上,所以我们不得不在第一层下面的另一层继续这个故事。这就是为什么照片中的地图有两层。

Then, if we were promoting the band someplace, we’d need to tell the story of the venue’s manager and the information he’d like to learn about the promotion. By this time, our map was wide enough that we bumped into the wall, so we had to continue the story in another layer below the first. That’s why the map in the photograph has two layers.

没有标题的图片

在讲故事的过程中,有时 Gary 会讲到他很兴奋的部分,然后他会开始描述很多细节。一张卡在另一张上面可以表示优先级。但它也可以表示分解,这只是一个花哨的词,表示较小的细节是更大事物的一部分。正如加里描述的细节,我会把它们记录在一张卡片上,并将它们放在上面大用户步骤的下面。例如,当加里描述制作乐队经理用来宣传演出的传单时,他格外热情,并且有很多细节需要讨论。

During the story, sometimes Gary would get to a part where he was excited and he’d start describing lots of details. One card above another can indicate priority. But it can also mean decomposition, which is just a fancy word for smaller details that are part of a bigger thing. As Gary described the details, I’d record them on a card, and place them below the big user step above. For instance, when Gary described creating the flyer that band managers would use to promote their gigs, he was extra passionate and had lots of details to discuss.

加里住在纽约市,当乐队撰写传单时,他想象着他看到的所有这些非常酷的东西都贴在纽约的墙壁和灯柱上。它们可能看起来像是用胶水和胶带粘在一起然后复印的,但有些真的很优雅和艺术。记录了一些细节后,我说,“我们回过头来再谈细节。让我们继续前进,让这个故事向前发展。” 很容易迷失在细节中,尤其是那些你热衷的细节。但是,当我们试图了解全局时,重要的是在了解所有这些细节之前先了解故事的结尾。至少在这个阶段,我在制图时使用的另一个口头禅是“一英里宽,一英寸深”——或者对于使用公制系统的理智国家的人来说:“一公里宽,一厘米深”。在迷失细节之前先了解故事的结尾。

Gary lived in New York City, and when bands are composing flyers he’s imagining all these really cool things he sees stuck on walls and lampposts in New York. They might look like they were put together with glue and tape and then photocopied, but some were really elegant and artistic. After recording a handful of details, I said, “Let’s come back and get to the details later. Let’s continue on and move this story forward.” It’s easy to get lost in the details, especially the ones you’re passionate about. But, when we’re trying to get the big picture, it’s important to get to the end of the story before catching all those details. Another mantra I use when mapping, at least at this stage, is “think mile wide, inch deep”—or for people in sane countries using the metric system: “kilometer wide, centimeter deep.” Get to the end of the story before getting lost in the details.

在深入研究之前,先关注故事的广度。

Focus on the breadth of the story before diving into the depth.

最终我们确实走到了加里故事的结尾。乐队经理成功地向成千上万的粉丝宣传了一场演出,演出取得了巨大的成功。到目前为止,我们的产品愿景都很清晰。我说,“现在让我们回去填写细节并考虑一些备选方案。”

Eventually we did get to the end of Gary’s story. The band manager had successfully promoted a gig to thousands of fans who spread the word, and the show was a wild success. The product vision so far was clear in both our heads. I said, “Now let’s go back and fill in the details and consider some of the alternatives.”

探索细节和选项

Explore Details and Options

在我们确定了故事地图的广度之后,它开始变厚。我们放在地图中每一列顶部的卡片变成了大东西,然后细节分解在它们下面。我们在用户故事的每一步停下来询问:

After we’ve got the breadth of the story map in place, it starts thickening up. The cards we put at the top of each of the columns in the map become big things, and then the details break down below them. We stop at each step in the user’s story and ask:

  • 他们会在这里做什么具体的事情?
  • What are the specific things they’d do here?
  • 他们可以做哪些替代的事情?
  • What are alternative things they could do?
  • 什么会让它真的很酷?
  • What would make it really cool?
  • 出现问题时怎么办?
  • What about when things go wrong?
没有标题的图片

最后,我们回去填写了很多细节。结果是我们讲述了乐队经理一天的生活故事,以及对乐队经理的成功很重要的其他人:粉丝和场地经理。

At the end of this we’d gone back and filled in a lot of details. The result was that we had told the story about a day in the life of a band manager, as well as the other people important to the band manager’s success: fans and venue managers.

我问加里,“现在呢?我们有所有这些其他用户,还有他们想做的其他事情——你想谈谈他们吗?你可以看到,如果我们继续谈话,我们将需要一个更大的房间。而且,加里,如果你做所有这些事情,那么构建这个产品将需要很多钱。我们可以讨论剩下的事情,但如果我们做了这么多,而你推出了你的产品,然后就这样做了,那看起来它会是一个有价值的产品。”

I asked Gary, “Now what? We have all these other users with other things they want to do—do you want to talk about them? You can see that if we keep talking we’ll need a bigger room. And, Gary, if you do all this stuff, it will take a lot of money to build this product. We could talk about the rest of this stuff, but if we built this much and you launched your product and just did this, that looks like it’d be a valuable product.”

加里同意了,他说:“我要到此为止了。”

Gary agreed, and he said, “I’m going to stop there.”

这个故事的悲伤部分是我问加里,“到目前为止你已经构建了很多软件,但是你构建的软件中有多少是在我们创建的这张地图上的?”

The sad part of this story is that I asked Gary, “You’ve been building a lot of software so far, but how much of the software you’ve built is on this map we’ve created?”

“几乎没有,”加里回答说,“因为当我列出清单并确定优先顺序时,我有点假设我们需要从其他地方开始。我当时在想这件事的整个宏伟愿景,我要花很多年才能达到的愿景,现在我们已经讨论过了,我根本不会从那里开始。”

“Nearly none of it,” Gary replied, “because when I built a list and prioritized things, I sort of assumed we needed to start somewhere else. I was thinking about the whole big vision of this thing, the vision that would have taken me years to reach, and now that we’ve had this discussion I wouldn’t have started there at all.”

故事地图是关于进行良好的老式对话,然后以地图的形式组织它。大多数人看的部分是地图——从左到右的形状,以及人们讲述一个大故事所采取的步骤。从上到下是关于细节的。但是构成产品框架并提供更多上下文的关键部分通常挂在地图上方和周围。它们是产品的目标,以及有关其客户和用户的信息。如果您将地图挂在墙上,您会发现在地图周围添加用户界面 (UI) 草图和其他注释是个好主意。

Story mapping is all about having a good old-fashioned conversation and then organizing it in the form of a map. The part that most people look at is the map—that left-to-right shape with the steps people take to tell a big story. The top to bottom is about the details. But the critical parts that frame the product and give more context are often hung above and around the map. They’re the product’s goals, and information about its customers and users. If you keep a map on the wall, you’ll find it’s good idea to add user interface (UI) sketches and other notes around the map.

在仅仅一天的合作中,加里和我就他想要构建的产品建立了共同的理解。但是我们头顶上形成了乌云,我们知道这一点。我们写的每张卡片中都有很多细节和更多讨论。而且,对于 Gary 来说,所有这些细节和所有这些讨论都等同于他需要花钱来构建软件——他没有的钱。他学到了关于软件开发的一个基本真理:要构建的东西总是比你有时间的多。

In just a day working together, Gary and I built shared understanding around the product he wanted to build. But there was a storm cloud forming above our heads, and we knew it. Inside each of those cards we wrote were lots of details and lots more discussions. And, for Gary, all those details and all those discussions equated to money he would need to spend to build software—money he didn’t have. He’d learned one of the fundamental truths about software development: there’s always more to build than you’ll have time for.

没有标题的图片

现在,Gary 对使用他的产品的人做出了很多其他重大假设,如果他们真的想要,或者真的可以按照他的设想使用它。但是,眼下,那些事情并不是他最关心的。他需要更加努力地工作,将他的产品创意最小化为首先可行的东西。

Now, there are a lot of other big assumptions Gary was making about the people who’d use his product, and if they really wanted to, or really could use it as he envisioned. But, right now, those things weren’t his biggest concern. He needed to work harder to minimize his product idea to something that was feasible first.

加里的故事最终有了一个圆满的结局。但在下一章中,我将讲述另一个组织的故事,该组织了解到自己要建设的东西太多了,以及它如何使用地图找到可行的解决方案。

Gary’s story eventually has a very happy ending. But in the next chapter I’ll tell the story of another organization that learned it had way too much to build, and how it used a map to find a viable solution.




[ 4 ]照片由 Piutus 拍摄,可在Flickr上找到,并已获得知识共享署名许可。

[4] Photo taken by Piutus, found on Flickr and licensed under the Creative Common Attribution license.

第 2 章计划少建

Chapter 2. Plan to Build Less

总有比你拥有的人力、时间或金钱更多的东西需要建造。总是。

There’s always more to build than you have people, time, or money for. Always.

说“总是”和“从不”这样的绝对词总是让我惹上麻烦。但是对于上面的陈述,老实说,尽管我没有科学数据来支持这一点,但我真的不记得有什么情况是不正确的。从来没有人来找我说,“我们被要求添加这个新功能,很高兴我们有比我们需要的更多的时间。”

Speaking in absolutes like “always” and “never” always gets me in trouble. But with the statement above, I honestly can’t recall a situation where it wasn’t true although I have no sciencey data to back this up. No one has ever once come to me saying, “We were asked to add this new feature, and happily we had lots more time than we needed.”

但使用故事地图最酷的事情之一是,它为您和其他合作者提供了一个空间来思考备选方案,并找到一种在您拥有的时间内取得出色成果的方法。

But one of the coolest things about using a story map is that it gives you and other collaborators a space to think through alternatives and to find a way to get a great outcome in the time that you have.

喝杯咖啡,坐在椅子上。是时候讲故事了。

Grab a cup of coffee and settle into your chair. It’s time for a story.

这个故事是关于我在全球最大媒体Globo.com的朋友们的公司在巴西。Globo.com 拥有电视台和广播电台,制作电视电影和原创节目,并出版报纸。它是巴西的媒体巨头,也是世界上最大的葡萄牙语媒体公司。

This story is about my friends at Globo.com, the largest media company in Brazil. Globo.com owns television and radio stations, produces made-for-TV movies and original programming, and publishes newspapers. It is a media monster in Brazil, and the largest Portuguese-language media company in the world.

Globo.com 比地球上的大多数组织更清楚什么是不可更改的最后期限。例如,它制作了一个很酷的梦幻足球游戏版本,每年都会为世界杯足球赛——地球上大多数人都称之为足球的运动——进行修改和改进。如果 Globo.com 迟迟不能开发该游戏,它就没有更改发布日期的奢侈。为什么不?因为世界其他地方不会重新安排世界杯。Globo.com 将为巴西将于 2016 年举办的奥运会制作专题报道和内容,我可以向您保证它会按时完成——它必​​须做到。它将为众多新电视节目和真人秀节目制作专题和内容。如果 Globo.com 迟到了,这些事情都无法重新安排。Globo.com 必须始终按时完成。而且,由于这是其业务的现实,Globo.com 擅长于此。这并不是因为该公司比其他所有人都快——当然,它很快,但没那么快。这是因为少做事是明智的。

Globo.com knows better than most organizations on the planet what unmovable deadlines really are. For example, it produces a cool version of a fantasy football game that’s revised and improved every year for World Cup soccer—the sport that most of the planet refers to as football. If Globo.com is late with development of that game, it doesn’t have the luxury of changing the release date. Why not? Because the rest of the world won’t reschedule the World Cup. Globo.com will produce features and content for the Olympics games that Brazil will host in 2016, and I can guarantee you that it’ll get it done in time—it has to. And it’ll produce features and content for the release of numerous new television programs and reality TV shows. None of these things can be rescheduled if Globo.com is late. Globo.com must always finish on time. And, since that’s the reality of its business, Globo.com is good at it. That’s not because the company is faster than everyone else—sure, it’s fast, but it’s not that fast. It’s because it’s smart about doing less.

映射帮助大团体建立共同理解

Mapping Helps Big Groups Build Shared Understanding

看看这个:

Take a look at this:

没有标题的图片

这只是来自 Globo.com 三个不同小组的八个团队的领导共同构建的一张相当大的地图的一部分。来自体育、新闻和娱乐的团队一起构建了这个,以思考他们需要做的工作来重建、改造和翻新他们的底层内容管理系统。这是驱动所有这些新闻网站、体育网站、肥皂剧网站、帮助宣传和招募真人秀节目的功能的系统,等等。这个庞大的系统需要能够处理大量的视频源、实时比分和选举结果、照片、突发新闻报道等等。它有很多事情要做,并且需要看起来很好。

That’s just a portion of a pretty big map built by leaders of eight teams from three different groups at Globo.com working together. The teams from Sports, News, and Entertainment built this together to think through the work they needed to do to rebuild, revamp, and renovate their underlying content management system. This is the system that drives all those news websites, sports websites, soap opera websites, features that help publicize and recruit people for reality TV shows, and much, much more. This massive system needs to be able to handle large quantities of video feeds, real-time scores and election results, photographs, fast-breaking news stories, and much more. It has a lot to do, and it needs to look good doing it.

当我在他们制作这张地图的那天到达 Globo.com 办公室时,一起工作的团队即将陷入扁平积压陷阱各个团队已经准备了各自的优先级积压工作。已经很清楚有大量工作要做,而且每个团队都相互依赖。例如,要推出一个好新闻网站,不仅需要新闻团队,还需要构建基础组件的所有其他团队,让新闻网站使用照片、视频、实时数据和许多其他内容。

When I arrived at the Globo.com offices the day they built this map, the teams working together were about to fall into the flat backlog trap. Individual teams had prepared their respective prioritized backlogs. It was already clear there was a huge amount of work to do, and each team depended on the other. For instance, to get a good news site out would need not just the news team, but also all the other teams that built the foundational components that let the news website use photos, videos, real-time data, and lots of other things.

我和他们坐下来,提醒他们一些他们已经知道的事情:“我知道你们是不同的团队,因为你们专注于不同的领域,但这是对一个内容管理系统的重大修订。你们必须一起释放。在您可以一起看到所有内容之前,您无法计划发布。你必须想象所有这些依赖关系。” 他们同意并迅速开始工作,将他们各自的积压工作重新组织成一张地图。在几个小时内,他们使用便利贴在墙上制作了一张地图,讲述了他们的内容管理系统的故事。

I sat down with them and reminded them of something they already knew: “I understand that you’re different teams because you’re focusing on different areas, but it’s a major revision of one content management system. You’ll have to release together. You can’t plan a release until you can see it all together. You’ve got to visualize all these dependencies.” They agreed and quickly went to work reorganizing their individual backlogs into a map. Within a few hours they built a map on the wall using sticky notes that told the story of their content management system.

当团队成员一起构建地图时,我不在房间里。但是当我当天晚些时候回来时,我对他们建造它的速度感到惊讶。他们对自己很满意,并且完全有权利这样做。他们理解了几个复杂的积压工作,将它们组织成一个连贯的产品故事。现在每个团队都可以看到自己的工作在大局中的位置。

I wasn’t in the room while team members worked together to build the map. But when I returned later in the day, I was amazed at how quickly they’d built it. They were pleased with themselves, and had every right to be. They’d made sense of several complex backlogs, organizing them into one coherent product story. And now each team could see where its work fit into the big picture.

映射跨多个团队的产品发布以可视化依赖关系。

Map for a product release across multiple teams to visualize dependencies.

映射可帮助您发现故事中的漏洞

Mapping Helps You Spot Holes in Your Story

当我与构建故事地图的人交谈时,他们会告诉我,“每次我们这样做都会发现漏洞。我们发现了一些我们认为应该由另一个团队负责但它不知道的事情。我们在我们忘记谈论的重要功能之间找到了必要的东西。” 通过一起映射,Globo.com 找到了其中的一些。

When I talk with people who have built story maps, they’ll tell me, “Every time we do this we find holes. We find things that we thought another team should be taking care of, but it didn’t know. We find the necessary stuff in between the big important features that we’d forgot to talk about.” By mapping together, Globo.com found some of that.

在您设想了整个产品或功能之后,开始玩“What-About”游戏就容易多了。这就是我们开始问的地方,“如果出现问题怎么办?” 或者“那些其他用户呢?” 玩 What-About 解决您的任何问题,并在地图主体上添加便利贴以获取您需要的功能创意,以便在您的软件中解决这些问题。在第 1 章中,加里玩 What-About 来考虑选择和备选方案。当您与其他团队一起这样做时,您会发现他们非常善于发现不同系统相互连接时可能出现的问题。

After you’ve envisioned the whole product or feature, it’s easier to start to play the “What-About” game. That’s where we start asking, “What about when this goes wrong?” Or “What about these other users?” Play What-About with any concern you have, and add stickies to the body of the map for feature ideas you’ll need in order to address these things in your software. In Chapter 1, Gary played What-About to consider options and alternatives. When you do this with other teams, you’ll find they’re terrific at spotting problems that might arise where different systems connect to each other.

人们有时对故事地图提出的批评之一是,每次他们坐下来创建故事地图时,他们最终都会得到太多。但我相信,我们现在只是找到了以后会伤害我们的东西,这是一件好事。

One of the criticisms people sometimes make about story mapping is that every time they sit down and create story maps, they end up with way too much. But it’s my belief that we’re just finding the stuff now that would have bitten us later on, and that’s a good thing.

在老式的软件开发方法中,当我们稍后发现新东西时——在我们已经估计交付时间并承诺交付日期之后——我们称这种新东西为范围蔓延我个人认为范围不会蔓延;理解增长。当人们构建其中一个故事地图时,他们会发现自己的理解存在漏洞。

In the old-school approach to software development, when we’d find that new stuff later on—after we’d already estimated delivery time and committed to a delivery date—we’d call that new stuff scope creep. I personally believe that scope doesn’t creep; understanding grows. And what happens when people build one of these story maps is that they find the holes in their understanding.

范围不会蔓延;理解增长。

Scope doesn’t creep; understanding grows.

总是太多

There’s Always Too Much

当我离开 Globo.com 的内容管理团队时,一切都很棒——相互理解,团队知道该做什么。然而,当我几天后回来与他们核实时,他们再次陷入困境,因为他们意识到有太多的工作要做,可能需要一年多的时间才能完成地图上的所有内容。当然,正如精明的读者所理解的那样,当软件开发人员说要花一年时间才能完成某件事时,他们实际上是指两年。这并不是因为他们不称职,或者他们的日程安排受到挑战,只是估计时间来做我们以前从未做过的事情是我们很不擅长的事情。而且,从本质上讲,我们通常是乐观的动物。

When I left the content management teams at Globo.com, everything was wonderful—understanding was rampant and the teams knew what to do. However, when I came back to check in with them a couple days later, they were struggling again because they realized that there was so much work to be done, that it would likely take more than a year to accomplish everything on the map. And, of course, as savvy readers can appreciate, when software developers say it’s going to take a year to get something done, they really mean two years. It’s not because they’re incompetent, or that they are calendar-challenged, it’s just that estimating the time to do something we’ve never done before is something we suck at. And, by nature, we’re often optimistic animals.

他们对我说:“太多了。我们在这里有很多事情要做,这需要很长时间。”

They said to me, “There’s way too much. We have a lot to do here and it’s going to take a long time.”

“你必须做这一切吗?” 我问。

“Do you have to do it all?” I asked.

他们当然回答说,“是的,因为它都是一个大型内容管理系统的一部分。”

They, of course, replied, “Yes, because it’s all part of one, big content management system.”

“但是这里的项目不会运行那么久,”我回答道。“我认识你们的 CEO,他希望更快地看到结果——对吧?”

“But projects don’t run that long around here,” I replied. “I know your CEO and he’s going to want to see results much faster—right?”

“是的,”他们证实,“他希望在几个月后即将举行的巴西大选中及时看到一些东西!”

“Yes,” they confirmed, “he wants to see something live in time for the upcoming Brazilian election in a few months!”

“你需要所有这些来为选举上线吗?” 我问。

“Do you need all of this to go live for the election?” I asked.

我一问这个问题,就看到灯泡亮了。当然,他们并不需要一切。到目前为止,他们一直专注于确定序列和依赖性,假设他们需要构建所有内容。他们做到了,但这实际上是时间问题。他们改变了想法,将重点放在结果上。

As soon as I asked the question, I could see light bulbs click on. Of course they didn’t need everything. Up ‘til now, they’d been focused on identifying sequence and dependency assuming they’d need to build everything. They did, but it was really a question of when. They shifted their thinking to focus on outcomes.

专注于您希望系统外部发生的事情,以决定系统内部的情况。

Focus on what you hope will happen outside the system to make decisions about what’s inside the system.

Globo.com 专注于巴西选举。这些团队特别考虑了在整个选举期间以更新、更性感的互动内容风格成功打动访客、广告商和 Globo 母媒体公司的伟大成果。如果他们那样做,他们就会赢。

Globo.com focused on Brazilian elections. The teams thought specifically about the great outcome of successfully impressing visitors, advertisers, and Globo’s parent media company with newer, sexier styles of interactive content throughout the election. If they did that, they’d have a win.

这不是他们第一次面对不可能的交货日期。他们考虑了一下,意识到他们肯定需要在新闻网站上线,并且可能需要一些其他支持它的东西,因为这是访问者和其他人会去监督巴西选举的地方。专注于新闻网站意味着关注创新的方式来更快地显示实时选举数据和突发新闻。当然,还有一个更新的、最新的视觉设计覆盖了一切。

This wasn’t their first time facing down an impossible delivery date. They thought about it for a bit, and realized that they definitely needed to go live with the news website, and potentially some other things that supported it because that’s where visitors and others would go to monitor Brazilian elections. Focusing on the news website meant paying attention to innovative ways to show real-time election data and breaking news stories faster. And, of course, there was a newer, up-to-date visual design overlaying everything.

切出最小可行产品发布

Slice Out a Minimum Viable Product Release

团队抓起一卷蓝色画家的胶带,在地图上从左到右拉伸线条以制作水平切片。然后,他们开始上下移动卡片,在蓝线上方和下方移动卡片,以指定哪些事情需要在第一个切片中完成,哪些可以稍后完成。

The teams grabbed a roll of blue painter’s tape and stretched lines across the map left to right to make horizontal slices. They then went to work moving cards up and down, above and below the blue lines to designate which things needed to be done in the first slice, and which could be done later.

没有标题的图片

思考过程有点像这样:如果我们为巴西大选直播,巴西的很多人都会看到这件事。它会溅起水花降落。它会影响我们的这些网站,我们会看起来很好。这片中的所有内容都是用户在软件发布后需要做的事情,这样他们才能引起轰动

The thought process worked a bit like this: If we go live for the Brazilian elections, a lot of people in Brazil will see this thing. It’s going to land with a splash. It’s going to affect these websites of ours and we’ll look good. Everything in this slice is what users will need to be able to do after the software is released so they can make that splash.

关注结果——用户需要做什么,看看系统什么时候出来——并分割出能给你带来这些结果的版本。

Focus on outcomes—what users need to do and see when the system comes out—and slice out releases that will get you those outcomes.

切出发布路线图

Slice Out a Release Roadmap

该地图包含可以改进所有 Globo.com 网络属性的创新内容。但要完成所有这些工作确实需要很长时间。抓住选举创造的市场窗口将是一个不容错过的大好机会。专注于此有助于 Globo 确定第一个版本。

The map contained innovative things that would improve all Globo.com’s web properties. But it really was going to take a long time to get all of it done. Hitting the market window that the elections created would be too big an opportunity to miss. Focusing on that helped Globo identify the first release.

然后,团队开始思考下一个版本应该锚定哪些类型的 Web 属性和市场事件。他们在每个切片的左侧张贴便签,用几个词描述他们对每个发布切片的意图——他们的目标结果。然后他们继续将卡片上下移动到正确的切片中。

The teams then went to work thinking about what kinds of web properties and market events should anchor the next releases. They posted sticky notes to the left of each slice with a few words describing their intention for each release slice—their target outcomes. Then they continued to move cards up and down into their correct slices.

没有标题的图片

最终,他们有了一个增量发布策略,让他们能够处理随着时间的推移更换整个内容管理系统所需的所有工作,并且以这样一种方式让他们看到每次发布都带来真正的好处。如果他们向下阅读地图的左边缘,他们会得到一个命名版本列表,每个版本都有特定的目标结果。这是一个发布路线图

In the end, they had an incremental release strategy that let them tackle all the work they needed to do to replace the whole content management system over time, and in such a way that they saw real benefit with each release. If they read down the left edge of the map, they had a list of named releases, each with specific target outcomes. This is a release roadmap.

请注意列表不是一堆功能。这是一份现实世界的好处清单——因为请记住,您的工作不是构建软件,而是改变世界。困难的部分是选择你想为哪些人改变世界,以及如何改变世界。

Notice how the list isn’t a bunch of features. It’s a list of real-world benefits—because, remember, your job isn’t to build software, it’s to change the world. The hard part is choosing which people you want to change the world for, and how.

关注特定的目标结果是确定开发工作优先级的秘诀。

Focusing on specific target outcomes is the secret to prioritizing development work.

反之亦然。也就是说,如果您不知道您的目标结果是什么——您想要获得的具体收益——那么几乎不可能确定优先级。

And the opposite is true as well; that is, if you don’t know what your target outcomes are—the specific benefits you’re trying to get—then prioritization is close to impossible.

不要优先考虑功能 - 优先考虑结果

Don’t Prioritize Features—Prioritize Outcomes

还要注意 Globo 团队是如何从更换整个内容管理系统的大目标开始的。替换内容管理系统是输出,他们要运送的东西。这样做会带来很多积极的结果。分解真正大块输出的秘诀是专注于更小的、特定的结果。

Notice also how the Globo teams started with a big goal of replacing their entire content management system. Replacing the content management system is the output, the stuff they were going to deliver. Doing that would result in lots of positive outcomes. The secret to breaking down that really big chunk of output was to focus on a smaller, specific outcome.

请记住:结果的背后是从事特定活动的特定人员的特定行为变化。通过关注即将举行的巴西选举,Globo 选择关注关注新闻的人,尤其是那些寻找最新选举细节的人。但是,在将重点放在这些人身上时,它忽略了肥皂剧爱好者、体育爱好者和许多其他类型的用户。那些其他人将不得不对当前站点感到满意一段时间。记住,你不可能总是取悦所有人。

Remember: behind outcomes are specific behavior changes for specific people engaged in specific activities. By focusing on the upcoming Brazilian elections, Globo chose to focus on the people who follow the news, especially those looking for up-to-the-minute election details. But, in placing its focus on those people, it left out soap opera lovers, sports lovers, and lots of other types of users. Those other people would have to be satisfied with the current site for a while longer. Remember, you can’t please everyone all the time.

这就是魔法——真的,它是

This Is Magic—Really, It Is

我可能很容易被打动,但切片是将软件创意组织成故事地图最酷的事情之一。

I may be easily impressed, but slicing is one of the coolest things about organizing software ideas into a story map.

很多时候,我和与我共事的团队都将我们关于完美产品的所有想法都放在了一张地图上,但如果我们创造这一切,我们将面临的工作量不知所措。这一切似乎都很重要。但随后我们退后一步,思考将使用我们产品的特定人群,以及他们需要完成什么才能取得成功。我们将其提炼成一两句话。然后我们切掉所有我们不需要的东西,我们对我们可行的解决方案实际上有多小感到震惊。这很神奇

Many times I, and the teams I’ve worked with, have placed all our ideas about the perfect product into a map and been overwhelmed by the amount of work we’d have if we created it all. It all seems important. But then we step back and think about the specific people who will use our product, and what they’ll need to accomplish to be successful. We distill that into a sentence or two. Then we carve away everything we don’t need, and we’re shocked at how small our viable solution really is. It’s magic.

第 1 章的Gary继续对他的产品做类似的事情。他最终将注意力集中在乐队经理、歌迷和 Mimi 的内部管理员身上——因为你必须让网站保持运行。加里选择将场地经理和制作音乐家排除在外。最后,他意识到,通过只关注那几个人和推广活动,他最终得到了一个很棒的电子邮件推广平台。所以,对于今天的 Mimi 用户来说,这就是您所知道的体验。

Gary from Chapter 1 went on to do something similar with his product. He eventually narrowed focus to the band manager, the fan, and Mimi’s internal administrator—because you’ve got to keep the site running. Gary chose to leave out venue managers and production musicians. In the end, what he realized is that by focusing on just those few people and the activity of promoting, he ended up with a great email promotion platform. So, for those of you who are Mimi users today, that’s the experience you know.

将我们的思维外化到一张可见的大地图中,可以使所有这些步骤变得更容易。它使许多人协作完成它成为可能。

Externalizing our thinking in a big visible map makes all these steps easier. It makes it possible for lots of people to collaborate to accomplish it.

为什么我们对 MVP 争论如此之多

Why We Argue So Much About MVP

有一个术语在软件开发行业中流行了很长时间:最小可行产品,或简称为 MVP。Frank Robinson 因最初创造了MVP一词而受到赞誉,但如今 Eric Ries 和 Steve Blank 的定义占主导地位。尽管有很多聪明人试图定义这个术语,但每个人似乎仍然感到困惑——包括我。我遇到的每个使用该术语的组织都略有不同。即使是同一个组织中的人和同一个对话也常常意味着不同的事情。

There’s a term that’s been kicking around in the software development industry for a long time: minimum viable product, or simply MVP. Frank Robinson is credited with originally coining the term MVP, but these days definitions from Eric Ries and Steve Blank dominate. In spite of multiple smart people trying to define the term, everyone still seems confused—including me. Every organization I run into that uses that term means something slightly different. Even people in the same organization and the same conversation often mean different things.

与字典中的大多数单词一样,它具有多重含义。我将为该术语给出三个定义:一个不好的定义和两个好的定义。

Like most words in the dictionary, it has multiple meanings. I’m going to give you three definitions for the term: a bad one, and two good ones.

这是坏的:

Here’s the bad one:

最小可行产品并不是你可能发布的最糟糕的产品。

Minimum viable product is not the crappiest product you could possibly release.

并且 MVP不是您的用户可以使用的产品,但只有在最简单的情况下,并且只有当他们有很高的痛苦阈值时才可以使用。我经常看到组织通过有人可以使用该产品的论点来合理化他们糟糕的产品决策,而当每个相关人员都清楚他们可能不会选择使用该产品时。

And the MVP isn’t the product that your users could use, but only in the simplest of circumstances, and only if they had a high threshold for pain. I commonly see organizations rationalizing their bad product decisions with the argument that someone could use the product, when it’s clear to everyone involved that they probably wouldn’t choose to.

如果 Globo.com 使用这个定义来分割它的第一个版本,它会产生负面结果。没有人会留下深刻印象。品牌会受到伤害,公司的境况会比什么都不发布还要糟糕。

If Globo.com had used this definition for slicing out its first release, it would have had a negative outcome. No one would have been impressed. The brand would have been hurt, and the company would have been worse off than if it had released nothing at all.

当我们在谈论活的有机体时使用术语viable时,它​​意味着有机体可以在世界上独立生存而不会死亡。当我们谈论软件时,我们指的是同一件事。

When we use the term viable when talking about a living organism, it means that an organism can survive in the world on its own without dying. And when we talk about software, we mean the same thing.

最小可行产品是成功实现预期结果的最小产品版本。

The minimum viable product is the smallest product release that successfully achieves its desired outcomes.

我最喜欢这个定义。最小值是一个主观术语。因此,请具体说明它的主观对象是谁——因为不是你。具体说明您的客户和用户是谁,以及他们需要完成什么。对他们来说最起码的是什么?我向你保证,这会对谈话有很大帮助。这仍然是一场艰难的谈话。但另一种方法是“HiPPO”方法——“最高收入者的意见”。那个更糟糕。

I like this definition best. Minimum is a subjective term. So be specific about who it’s subjective to—because it’s not you. Be specific about who your customers and users are, and what they need to accomplish. What’s minimum to them? I promise you, it’ll help the conversation hugely. It’s still a tough conversation. But the alternative is the “HiPPO” method—the “highest paid person’s opinion.” That one sucks worse.

这些天我更喜欢的术语是minimum viable solution我与组织合作的大部分事情都不是完整的新产品。它们是新特性或功能,或者是对现有特性的改进。所以术语解决方案似乎更有意义。所以让我修改一下我的定义:

The term I prefer these days is minimum viable solution. Most of the things I work with organizations on aren’t whole, new products. They’re new features or capabilities, or improvements on features already out there. So the term solution seems to make more sense. So let me revise my definition:

最小可行解决方案是成功实现预期结果的最小解决方案版本。

The minimum viable solution is the smallest solution release that successfully achieves its desired outcomes.

困难的部分来了……

Here comes the hard part…

我们只是在猜测。

We’re just guessing.

当我们切出一堆软件功能并将其称为最小可行解决方案时,我们真的不知道它是否是。

When we slice out a bunch of software functionality and call it a minimum viable solution, we don’t really know if it is.

结果的问题在于,在事情出现之前,你无法真正观察到它们。当你切出一个版本时,你不得不假设会发生什么。您可能不得不猜测哪些客户会购买您的产品,哪些用户会选择使用它,如果他们可以使用它,以及在您有的时间内构建什么是可行的。你不得不猜测有多少会让他们开心。这是很多猜测。

The problem with outcomes is that you can’t really observe them until things come out. When you slice out a release, you’re forced to hypothesize what will happen. You might have to guess about what customers will buy your product, what users will choose to use it, if they can use it, and what’s feasible to build in the time you have. You’re forced to guess at how much will make them happy. That’s a lot of guessing.

这很糟糕,因为如果你猜得太低,好吧,那还不到最小值,你就失败了。如果你猜得太高,很多人都会这样做来对冲他们的赌注,那么你就花了太多钱,而且常常冒着根本无法完成事情的风险。最糟糕的是,你可能完全错了,你运送的东西再多也无足轻重。

This sucks, because if you guess too low, well, that’s less than minimal, and you’ve failed. If you guess too high, which many people do to hedge their bets, then you’ve spent too much money and often risk not getting things done at all. And worst of all, you could be just dead wrong, and no amount of what you ship will matter at all.

难怪“你可能发布的最糟糕的产品”的定义仍然盛行。因为那是我们不需要猜测的。

It’s no wonder that the “crappiest product you could possibly release” definition still thrives. Because that’s the one we don’t need to guess about.

新的 MVP 根本不是产品!

The New MVP Isn’t a Product at All!

我知道你们中的一些人可能在最近几章中感到越来越紧张。您可能会想,Jeff 忽略了最重要的事情!你可能是对的。你最重要的一些事情在故事和故事地图对话中可以讨论的是:

I know that some of you may have been feeling progressively twitchy over the last couple of chapters. You may have thought to yourself, Jeff’s overlooking the most important thing of all! And you might be right. Some of the most important things you can discuss during story and story map conversations are:

  • 我们最大、最危险的是什么假设?不确定性在哪里?
  • What are our biggest, riskiest assumptions? Where is the uncertainty?
  • 我可以做些什么来学习一些可以用真实信息代替风险或假设的东西?
  • What could I do to learn something that would replace risks or assumptions with real information?

这引出了我对 MVP 的第三个定义,正如 Eric Ries 在他的《精益创业》(皇冠企业)一书中所推广的那样。像我们大多数人一样,埃里克通过惨痛的教训了解到,我们只是在猜测。埃里克在一家公司工作,该公司发布了一种它认为可行的产品,但这是错误的。他明智地改变了策略,将重点放在学习上——专注于验证公司在第一个 MVP 版本中所做的所有假设。埃里克提出了一个重要的观点,即我们需要创建更小的实验、原型来检验我们关于什么是最小和可行的假设。如果你采用埃里克的思维方式,你应该这样做,你的第一个产品真的应该是一个实验——然后是一个实验,然后是一个实验,直到你真正证明你得到了正确的产品。

This leads me to my third definition of MVP, as popularized by Eric Ries in his book The Lean Startup (Crown Business). Eric learned the hard way, as most of us do, that we’re just guessing. Eric worked for a company that released a product that it thought was viable, but it was wrong. Intelligently, he changed his strategy to focus on learning—to focus on validating all those assumptions the company had made in its first MVP release. Eric makes the important point that we need to create smaller experiments, prototypes that test our hypothesis about what’s minimal and viable. And if you adopt Eric’s way of thinking, which you should, your first product should really be an experiment—and the one after that, and the one after that, until you really prove that you’ve got the right product.

一个最小的可行产品也是你可以创造或做的最小的事情来证明或反驳一个假设。

A minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption.

虽然 Globo.com 的人们能够制定减少建设的计划非常酷,但他们并不是在自欺欺人。他们知道还有很多东西需要学习来证明他们的假设是正确的。他们和其他所有人都需要从这里制定计划以了解更多信息。这就是我们将在下一章中讲述我们的故事的地方。

While it was pretty cool that the folks at Globo.com were able to create a plan to build less, they weren’t fooling themselves. They knew there was lots left to learn to prove their assumptions were good. From here they and everyone else need to create a plan to learn more. And that’s where we’ll pick up our story in the next chapter.

第 3 章计划更快地学习

Chapter 3. Plan to Learn Faster

这是我的朋友埃里克,站在他的团队房间里他的积压工作和任务板前。他是一名产品负责人,与他的团队一起努力打造一款成功的产品,但现在并非如此。不过,埃里克并不担心。他有一个使他的产品成功的策略。到目前为止它正在工作。

This is my friend Eric, standing in front of his backlog and task board in his team room. He’s a product owner working hard with his team to build a successful product, but right now it’s not. That doesn’t worry Eric, though. He has a strategy for making his product successful. And so far it’s working.

没有标题的图片

Eric 在一家名为 Liquidnet 的公司工作。Liquidnet 是面向机构投资者的全球交易网络。早在埃里克站在照片中的董事会面前之前,他公司的某个人就确定了一组 Liquidnet 可以更好地服务的客户,以及一些如何做到这一点的想法。Eric 是采纳这些想法并付诸实施的团队的一员。这就是产品所有者所做的。如果你认为他们总是按照自己的伟大想法行事,那你就错了。成为产品负责人最困难的部分之一是拥有他人的想法并帮助使其成功,或者证明它不太可能成功。最好的产品负责人,如埃里克,帮助他们的整个团队获得产品的所有权。

Eric works for a company called Liquidnet. Liquidnet is a global trading network for institutional investors. Long before Eric came to stand in front of the board in the picture, someone at his company identified a group of customers Liquidnet could serve better, along with a few ideas of how to do that. Eric is part of a team that took those ideas and ran with them. That’s what product owners do. If you thought they were always acting on their own great ideas, well, you’re wrong. One of the hard parts of being a product owner is taking ownership of someone else’s idea and helping to make it successful, or proving that it isn’t likely to be. The best product owners, like Eric, help their entire team take ownership of the product.

从讨论您的机会开始

Start by Discussing Your Opportunity

Eric 并没有通过积压用户故事来开始他的工作。他从某人的伟大想法开始,并将其视为公司的机会——因为它确实是。他与公司的领导层进行了交谈,以了解更多信息。他们讨论:

Eric didn’t start his work by building a backlog of user stories. He started with the big idea someone had, and treated it like an opportunity for his company—because it was. He had conversations with leadership in his company to understand more. They discussed:

  • 什么是大创意?
  • What is the big idea?
  • 谁是客户?我们认为哪些公司会购买该产品?
  • Who are the customers? Who are the companies we think would buy the product?
  • 谁是用户?我们认为这些公司中的哪些人会使用该产品,他们将使用该产品做什么?
  • Who are the users? Who are the types of people inside those companies we think would use the product, and what would they be using it for?
  • 他们为什么要它?它将为客户和用户解决他们今天无法解决的哪些问题?他们会从购买和使用中得到什么好处?
  • Why would they want it? What problems would it solve for customers and users that they couldn’t solve today? What benefit would they get from buying and using it?
  • 我们为什么要建造它?如果我们构建了这个产品并且它成功了,这对我们有什么帮助?
  • Why are we building it? If we build this product and it’s successful, how does that help us?

Eric 需要先与组织中的其他人建立共识,然后才能抓住机会。他知道在接下来的几个月里他需要多次讲述这个产品的故事,所以他最好现在就开始做大事。

Eric needed to build shared understanding with others in his organization before he could take ownership of the opportunity. He knew he was going to need to tell the story of this product many times over the coming months, so he’d better get the big stuff right now.

您的第一个故事讨论是为了构建机会。

Your first story discussion is for framing the opportunity.

验证问题

Validate the Problem

埃里克相信领导的直觉,但他知道这个伟大的想法只是一个假设。他知道确保想法成功的唯一方法是当他们真正看到它成功时。

Eric trusts his leadership’s intuition, but he knows that this big idea is a hypothesis. He knows the only way to be sure the idea will succeed is when they actually see it succeed.

他首先花时间直接与客户和用户交谈,以真正了解他们。在此过程中,他确认确实有客户遇到了问题,而且他们确实有兴趣购买解决方案。埃里克与可能使用该产品的人交谈。他们没有今天的产品,而且只有很差的解决方法来解决新产品创意可以解决的问题。

He first spent time talking to customers and users directly to really learn about them. Along the way he validated that there really were customers who had the problem, and they really were interested in buying a solution. Eric talked to the people who’d likely use the product. They didn’t have the product today, and had only poor workarounds to address the problems the new product idea would solve.

验证您正在解决的问题确实存在。

Validate that the problems you’re solving really exist.

在 Eric 与客户和用户交谈的同时,他一直在建立一个他认为适合试用他的新软件的人选。一些公司将这些人称为客户开发伙伴。跟踪这个细节,因为它会在故事的后面出现。

While Eric’s been talking with customers and users, he’s been building up a pool of people he thinks are good candidates to try his new software. Some companies refer to these people as customer development partners. Keep track of this detail, because it’s going to come up later in the story.

实际上,在这个阶段,不仅仅是埃里克。Eric 与一小群其他人一起工作,他们花了很多时间与客户交谈,在这样做的过程中,他发现解决问题并不那么容易——而且还有其他问题需要首先解决。你要带走的重要一点是,他们学得越多,原来的机会就改变得越多——最终改变了很多。幸运的是,他们并没有按照要求去做。那不会为他们的客户或他们的组织服务。

Actually, during this stage, it wasn’t just Eric. Eric was working with a small team of others who spent lots of time talking to their customers, and, in doing so, found that solving the problem wasn’t so easy—and that there were other problems that needed to be solved first. The important thing for you to take away is that the more they learned, the more the original opportunity was changed—eventually, a lot. It’s lucky they didn’t just get to work building what they were told to. That wouldn’t have served their customers or their organization.

到目前为止,埃里克和他的团队在与客户交谈后,对他们可以构建用户可以使用的解决方案类型有了具体的想法,并通过这样做获得他们的雇主想要的好处。现在,埃里克和他的团队可以在这里“全力以赴”——他们可以赌上一切。他们本可以积压一些故事来描述他们的解决方案,然后组建一个团队来构建它。因为他们是聪明人,所以他们会使用故事地图从大创意转移到要构建的具体部分。但是,因为他们真的很聪明,所以他们此时要做的最后一件事就是构建软件。

By now Eric and his team, after talking to customers, had specific ideas for the type of solution they could build that users could use, and by doing so get the benefit their employers wanted. Now, here’s where Eric and his team could have gone “all in”—where they could have bet it all. They could have built a backlog of stories that described their solution and set a team to work building it. Because they’re smart people, they’d have used a story map to move from the big idea to the specific parts to build. But, because they’re really smart, the last thing they’re going to do at this point is to build software.

原型学习

Prototype to Learn

正是在这里,埃里克开始担任该产品的所有者。他首先将他的解决方案设想为一堆简单的叙事故事——用户场景。然后他开始将这个想法设想为一个简单的线框草图。然后他创建了一个更高保真度的原型。这不是工作软件。这是一个简单的电子原型,使用 Axure 或 PowerPoint 等简单工具创建。

It’s around here that Eric began to act as the owner for this product. He moved to envision his solution first as a bunch of simple narrative stories—user scenarios. Then he moved to envisioning the idea as a simple wireframe sketch. And then he created a higher-fidelity prototype. This wasn’t working software. It was a simple electronic prototype, created with a simple tool like Axure, or maybe even PowerPoint.

所有这些都是 Eric 的学习步骤。他们帮助他设想他的解决方案。最终,他想将他的解决方案展示在用户面前,看看他们的想法。但他知道,在将其摆在他们面前之前,他首先需要确信它能解决他们的问题。

All of these are learning steps for Eric. They help him envision his solution. Ultimately, he wants to put his solution in front of his users to see what they think. But he knows he first needs to feel confident it solves their problems before he puts it in front of them.

草图和原型,以便您可以设想您的解决方案。

Sketch and prototype so you can envision your solution.

现在,我对你隐藏了一个重要的细节。Eric 实际上是一名交互设计师。他是那种习惯于与客户和用户共度时光,并习惯于构建这些简单原型的设计师。但是,对于这个新产品,他也是产品负责人——对产品的成功负最终责任的人。Eric 公司的其他产品负责人没有他的设计技能,他们非常明智地与设计师结对,以帮助采访用户和构想解决方案。

Now, I’ve hidden an important detail from you. Eric was actually an interaction designer. He’s the kind of designer who’s used to spending time with customers and users, and used to building these simple prototypes. But, for this new product, he’s also the product owner—the one ultimately responsible for the product’s success. There are other product owners in Eric’s company who don’t have his design skills, and they very sensibly pair with designers to help with both interviewing users and envisioning solutions.

Eric 最终确实将原型带回给了用户。我当时不在场,所以我不知道 Eric 到底发生了什么。但我遇到过很多次这种情况,而且我总是对我从真正使用我的解决方案的人那里学到的东西感到惊讶。我只能告诉你的是,为惊喜和坏消息做好准备。事实上,庆祝这个坏消息,因为你可能会在几个月后,在你构建软件之后收到同样的坏消息。那才是真正糟糕的时候。现在,进行更改的成本很低,您应该这样做。埃里克做到了。

Eric did eventually bring prototypes back to users. And I wasn’t there, so I don’t know what really happened for Eric. But I’ve been in these situation lots of times, and I’m always surprised about what I learn from the people who’ll really use my solution. All I can tell you is, be prepared for surprises and bad news. In fact, celebrate the bad news, because you could have received the same bad news months later, after you’d built the software. That’s when it really sucks. Right now, it’s cheap to make changes, and you should. And Eric did.

与用户一起制作原型并进行测试,以了解您的解决方案是否有价值和可用。

Prototype and test with users to learn whether your solution is valuable and usable.

在多次迭代他的解决方案并将其展示给客户后,Eric 确信他有一个非常好的解决方案创意。当然,现在他可以建立积压工作,并让他的开发团队着手将原型解决方案转变为真正可用的软件。但埃里克不会那样做。好吧,不完全是这样。这是一个比他愿意接受的更大的赌注。

After iterating his solution many times and showing it to his customers, Eric was confident he had a pretty good solution idea. Surely now he could get that backlog built, and get his team of developers to work turning that prototyped solution into real working software. But Eric’s not going to do that. Well, not exactly that. That’s a bigger bet than he’s willing to take.

注意人们所说的他们想要什么

Watch Out for What People Say They Want

Eric 对他认为可行的解决方案进行了原型设计。但他不确定它是否是最小的——因为他向人们展示了很多很酷的想法。如果你向人们展示所有很酷的想法,他们当然会喜欢它们。但埃里克知道他的工作是尽量减少他建造的数量并仍然让人们开心。他能拿走多少,仍然有可行的解决方案?

Eric has prototyped what he believes is a viable solution. But he’s not really sure if it’s minimal—because he showed people lots of cool ideas. And if you show people all the cool ideas, of course they’ll love them. But Eric knows his job is to minimize the amount he builds and still keep people happy. How much could he take away and still have a viable solution?

埃里克还知道一些有点令人不安的事情。他知道那些说他们喜欢它并使用它的人也只是在猜测。

Eric also knows something else that’s a bit disturbing. He knows the people who said they’d like it and use it are just guessing, too.

回想一下你自己买东西的时候。您可能看过产品。您可能已经看到销售人员演示了很酷的功能。您可能已经亲自试用了这些很酷的功能,并且您可以想象真正使用并喜欢该产品。但是当你购买产品并真正开始使用它时,你会发现这些很酷的功能并没有那么重要。真正重要的是您没有想到的功能。而且,最糟糕的是,也许你根本不需要那么多产品。好吧,也许这只是我在说的。但是我的车库里有很多东西我希望我从来没有买过。

Think back to when you’ve bought something yourself. You may have looked at the product. You might have watched a salesperson demonstrate the cool features. You may have tried out the cool features for yourself, and you could imagine really using and loving the product. But when you bought the product and actually started using it, you found the cool features didn’t matter so much. What really mattered were features you hadn’t thought about. And, worst of all, maybe you didn’t really need the product that much after all. OK, maybe it’s just me I’m talking about. But I’ve got lots of stuff in my garage that I wish I’d never bought.

回到埃里克。他知道他的客户和用户可以想象该产品会很好用,并且知道这一点让他有信心加大赌注。但真正的证据是那些人每天都选择使用它。这就是他正在寻找的真正结果——也是能让他的公司获得真正想要的利益的唯一结果。要了解这一点,需要的不仅仅是原型。

Back to Eric. He knows his customers and users can imagine the product would be great to use, and knowing that gives him the conviction to up his bet. But the real proof is when those people actually choose to use it every day. That’s the real outcome he’s looking for—and the only outcome that’ll get his company the benefit it really wants. And it’s going to take more than a prototype to learn that.

构建学习

Build to Learn

现在,埃里克在这里展示了他的聪明才智。

Now, here’s where Eric gets to show how smart he really is.

Eric 和他的团队确实开始着手构建软件。但他们的首要目标不是构建最小可行产品。实际上,它是为了构建一些不那么简单的东西——刚好足以让潜在用户可以用它做一些有用的事情。这是一款不会给太多人留下深刻印象的产品,他们甚至可能会讨厌它。这绝对不是您希望营销和销售人员推销的产品。事实上,您唯一希望看到该产品的人是有一天可能会使用该产品并且真诚地关心找到能够解决他们问题的产品的人。

Eric and his team actually do get to work building software. But their first goal isn’t to build a minimum viable product. Actually, it’s to build something less than minimal—just enough that potential users could do something useful with it. This is a product that wouldn’t impress too many people, and they might even hate it. It’s definitely not a product you’d want your marketing and sales people out there pitching. In fact, the only people you’d want to see this product are people who may one day use the product, and honestly care about finding a product that solves their problem.

恰好,埃里克身边就有一小群这样的人。这是他在了解和验证问题时与之合作的客户和用户。他们是他的发展伙伴。他们是对早期原型提供反馈的人。埃里克认为其中有一部分最能帮助他学习。他们是他会把这个低于最低限度——而且绝对不可行的——产品放在第一位的人。他希望他们能成为他的早期采用者。

It just so happens that Eric has a small group of people just like that. It’s the customers and users he worked with earlier when he was learning about and validating the problem. They’re his development partners. They’re the ones who gave feedback on early prototypes. And there’s a subset of them that Eric believes can best help him learn. They’re the ones he’ll put this first, less-than-minimum—and definitely not viable—product in front of. He hopes they’ll become his early adopters.

他就是这么做的。

And that’s what he did.

没有标题的图片

这是 Eric 指出他当前积压的一部分。拍摄这张照片时,他已经向他的开发合作伙伴发布了软件。在他这样做之后,他特意与他们交谈以获取他们的反馈。他的团队还建立了一些简单的指标,这样他们就可以衡量人们是否真的在使用该软件,以及他们具体在软件中做了什么。

This is Eric pointing out a slice of his current backlog. When this picture was taken, he’d already released software to his development partners. After he did, he made a point of talking to them to get their feedback. His team also built in some simple metrics so they could measure whether people were really using the software, and what they did in the software specifically.

埃里克知道人们很有礼貌。他们可能会说他们喜欢某个产品,但从不使用它。“使用它”是他想要的真正结果,礼貌对他没有帮助。Eric 也知道有些人要求很高。他们可能会列出产品存在的所有问题,或者抱怨错误,但指标可能会告诉我们他们每天都在使用它。这是一件好事,尽管他们一直在抱怨。抱怨也很好,因为它让埃里克知道他下一步应该改进的地方。

Eric knows that people are polite. They may say they like a product, but then never use it. The “using it” is the real outcome he wants, and polite isn’t helping him. Eric also knows some people are demanding. They may list all the problems the product has, or complain about bugs, but the metrics may be telling us that they use it every day anyway. And that’s a good thing, in spite of all their complaining. The complaining is good, too, because it gives Eric ideas about where his next improvements should be.

Eric 的积压工作被组织成一个故事地图,顶部用黄色便签纸表示主干。那些黄色的便利贴上有简短的动词短语,讲述了他的用户将在产品中做什么的大故事,但是是在高层次上。下面是所有细节——他们将做的具体事情以及真正使用该产品所需的事情。虽然他和他的团队处理的细节随着版本的不同而变化,但主干仍然非常一致。

Eric’s backlog is organized as a story map with the backbone in yellow stickies across the top. Those yellow stickies have short verb phrases on them that tell the big story of what his users will do in the product, but at a high level. Below it are all the details—the specific things they’ll do and need to really use the product. While the details he and his team work on change from release to release, the backbone stays pretty consistent.

磁带上方的顶部切片是埃里克和他的团队目前正在制作的切片。此版本需要 Eric 进行两次冲刺。他正在使用 Scrum 开发流程,其中他的冲刺是两周的时间盒。所以两次冲刺基本上相当于一个月。在其下方是沿着电路板运行的切片。下一个切片包含他们认为下一个版本可能是什么,等等。在每个切片的左边,就像 Globo.com 团队一样,挂了一张便签,上面有发布名称和一些关于他们想在此版本中学习的内容。除了最高版本,上面张贴了呆伯特卡通片。这是他们团队的一个内部笑话,我没有参与其中。

The top slice, above the tapeline, is the one Eric and his team are working on right now. This release will take Eric two sprints. He’s using a Scrum development process where his sprints are two-week time-boxes. So two sprints equate to basically a month. Below that are slices running down the board. The next slice contains what they think the next release might be, and so on. To the left of each slice, just as with the Globo.com team, hangs a sticky note with the release name and a few words about what they want to learn in this release. Except for the top release, which has a Dilbert cartoon posted over it. It’s an inside joke in their team that I wasn’t in on.

没有标题的图片

如果仔细观察,当前切片的顶部有点被清理掉了。我在它们原来所在的地方画了一些便利贴。但它们已经不存在了,因为那些在上面的东西是他的团队将首先建造的东西。当团队成员一起工作来计划他们的工作时,他们移除了那些便利贴并将它们放在任务板上,位于故事地图待办事项列表的右侧。该任务板显示了他们现在在这个冲刺中正在处理的故事,以及交付任务——开发人员和测试人员需要做的具体事情,以将故事中的想法转化为可用的软件。

If you look closely, the top of that current slice is sort of cleaned out. I’ve drawn in some sticky notes where they used to be. But they’re not there anymore because those things that were on the top are the first things his team will build. As the team members worked together to plan their work, they removed those sticky notes and placed them on a task board to the right of the story-mapped backlog. That task board shows the stories they’re working on now in this sprint, along with delivery task—the specific things that the developers and testers will need to do to turn the ideas in the story into working software.

埃里克的故事地图积压工作中有一个更妙的地方,也是证明他聪明的一个地方,就是最上面那部分的厚度。它的厚度是它下面的切片的两倍。当 Eric 和他的团队完成切片并交付时将它交给他们的开发合作伙伴——他们称之为测试版客户——他们会将便利贴从下面的切片中移上去。当他们这样做时,他们将对下一个分割版本进行更详细的讨论。他们会玩 What About 来发现问题并填写详细信息。他们将在下一个版本中讨论一些想法,这次讨论可能会导致他们将大想法分成两个或三个较小的想法。然后,他们将需要该切片中的垂直高度来确定优先级 - 以选择首先构建的内容。

One finer point of Eric’s story-mapped backlog, and one that proves he’s smart, is the thickness of that topmost slice. It’s twice as thick as the slices below it. When Eric and his team finish a slice and deliver it to their development partners—what they call their beta customers—they’ll move the sticky notes up from the slice below. When they do, they’ll have lots more detailed discussion about this next sliced-out release. They’ll play What About to find problems and fill in details. They’ll talk about some of the ideas in the next release, and this discussion may result in their splitting the big idea into two or three smaller ideas. And then, they’ll need the vertical height in that slice to prioritize—to make choices about what to build first.

看看他们有多聪明?

See how smart they are?

迭代直到可行

Iterate Until Viable

埃里克可能已经开始了整个过程,关于最小可行产品可能是什么的想法,但他故意构建了一些不最小的开始。然后他每个月都会增加一点。他从他的开发合作伙伴那里得到反馈——既有与他们交谈的主观内容,也有他从查看数据中获得的更客观的内容。

Eric may have started this whole process with an idea about what the minimum viable product might be, but he’s purposely built something less than minimal to start with. He’s then adding a bit more every month. He’s getting feedback from his development partners—both the subjective stuff from talking to them, and the more objective stuff he gets from looking at data.

他将保持这一策略,慢慢地发展和改进产品,直到他的开发合作伙伴真正开始定期使用该产品。事实上,埃里克希望他们成为向其他人推荐产品的人——真正的参考客户。当他们这样做时,他就知道自己找到了最低限度可行的方法。那时产品可以安全地投放市场并疯狂销售。如果埃里克和他的团队以前曾尝试出售它,他们最终会遇到很多失望的客户——与他在整个过程中建立私人关系的那些人相比,他们要友好得多。

He’ll keep up this strategy, slowly growing and improving the product, until his development partners actually start using the product routinely. In fact, what Eric’s hoping for is that they become people who’d recommend the product to other people—real reference customers. When they do, that’s when he knows he’s found minimum and viable. And that’s when the product is safe to market and sell like crazy. If Eric and his team had tried to sell it before, they’d have ended up with lots of disappointed customers—people a lot less friendly than those with whom he built personal relationships throughout this process.

如何以错误的方式做到这一点

How to Do It the Wrong Way

埃里克本可以做的是把他最后的、最好的原型,分解成所有的组成部分,然后开始一部分一部分地构建它。许多个月后,他会有一些东西要释放。如果他的大猜测是正确的,他就会知道。在这一点上你需要相信我,但它不会是——因为它很少是。

What Eric could have done is to take his last, best prototype, break it down into all its constituent parts, and start building it part by part. Many months later, he’d have had something to release. And he’d have learned then if his big guess was right. You’ll need to trust me on this, but it wouldn’t have been—because it rarely is.

没有标题的图片

这是我的朋友 Henrik Kniberg 制作的简单可视化。它很好地说明了一个失败的发布策略,在每次发布时我都会得到一些我不能使用的东西,直到最后一次发布时我得到了我可以使用的东西。

This is a simple visualization made by my friend Henrik Kniberg. It beautifully illustrates a broken release strategy where at every release I get something I can’t use, until the last release when I get something I can.

Henrik 建议采用这种替代策略:

Henrik suggests this alternative strategy:

没有标题的图片

如果我以这种方式计划我的发布,那么在每次发布中我都会提供一些人们可以实际使用的东西。现在,在这个愚蠢的交通示例中,如果我的目标是长途旅行并随身携带一些东西,而你给了我滑板,我可能会感到有点沮丧。我会让你知道带着那东西长途旅行是多么困难——尽管在车道上闲逛很有趣。如果你的目标是让我高兴,你可能会为此感到难过。但你真正的目标是学习,你做到了。所以这很好。你了解到我想去更远的地方旅行,如果你接受了它,你也会了解到我很重视玩得开心。

If I plan my releases this way, in each release I deliver something people can actually use. Now, in this silly transportation example, if my goal is to travel a long distance and carry some stuff with me, and you gave me a skateboard, I might feel a bit frustrated. I’d let you know how difficult it was to travel long distances with that thing—although it was fun to goof around with it in the driveway. If your goal was to leave me delighted, you might feel bad about that. But your real goal was to learn, which you did. So that’s good. You learned I wanted to travel farther, and if you picked up on it, you also learned I valued having fun.

在 Henrik 的进度中,自行车发布前后情况开始好转,因为我实际上可以将其用作足够的交通工具。而且,在摩托车级别,我真的可以看到这对我有用——而且我也很开心。这对我来说可能是最低限度和可行的。如果我真的喜欢摩托车,也许我的下一个最佳选择是更大、更快的哈雷戴维森,而不是跑车。我现在正走向中年危机,哈雷听起来不错。但在我试过摩托车之后,我们都从中学到了一些东西,我们才能做出最好的决定。

In Henrik’s progression, things start picking up at around the bicycle release because I can actually use it as adequate transportation. And, at about motorcycle level, I can really see this working for me—and I’m having fun too. That could be minimum and viable for me. If I really love the motorcycle thing, maybe my next best step would be a bigger, faster Harley-Davidson, and not a sports car. I’m headed for a midlife crisis right now and that Harley is sounding pretty good. But it’s after I try the motorcycle, and we both learn something from that, that we can best make that decision.

将每次发布都视为一次实验,并注意你想要学习的内容。

Treat every release as an experiment and be mindful of what you want to learn.

但是那些需要长途旅行和有孩子的人呢?对于目标市场,这些都不是好的选择。

But what about other folks who need to travel longer distance, and who have kids? For that target market, none of these would be good choices.

始终牢记您的目标客户、用户和您希望的结果。从所有类型的用户那里获得同样好的结果真的很难。所以专注。

Always keep your target customers, users, and the outcomes you’re hoping for in mind. It’s really tough to get the same great outcome from all types of users. So focus.

验证学习

Validated Learning

我的朋友埃里克所做的是应用经过验证的学习策略——精益创业思想中的一个重要概念。埃里克知道他正在解决的问题,他正在解决的客户和用户,以及他想到的解决方案都是假设。其中很多都是非常好的假设。但它们都是相同的假设。Eric 着手了解这些假设,然后验证它们,从客户和用户面临的问题转向他为他们提供的解决方案。在每一步中,他都以学习某些东西为明确目标来做或构建一些东西。

What my friend Eric did is apply a validated learning strategy—one of the important concepts in Lean Startup thinking. Eric knew that the problems he was solving, the customers and users he was solving them for, and the solutions he had in mind were all assumptions. Lots of them were pretty good assumptions. But they were assumptions just the same. Eric set out to understand the assumptions and then validate them, moving from the problems customers and users faced to the solutions he had for them. At each step he did or built something with the explicit goal of learning something.

没有标题的图片

Eric 所做的是 Eric Ries 描述的构建-测量-学习循环的核心。根据 Ries 的定义,Eric 发布的每个版本都是最小可行产品。但您可以看到,在他的目标客户和用户眼中,它是不可行的——至少目前还不行。出于这个原因,我喜欢将 Ries 的 MVP 称为最小可行产品实验——或简称 MVPe。这是我可以构建的最小的东西来学习一些东西。我所学到的是推动了解在我的目标客户和用户眼中什么是真正可行的。

What Eric did is the heart of the build-measure-learn loop described by Eric Ries. And by Ries’s definition, each release that Eric shipped was a minimum viable product. But you can see that it wasn’t viable in the eyes of his target customers and users—at least, not yet. For that reason, I like referring to Ries’s MVP as a minimum viable product experiment—or MVPe for short. It’s the smallest thing I could build to learn something. And what I learn is driving toward understanding what’s really viable in the eyes of my target customers and users.

Eric 在此过程中使用了很多工具和技术。但用文字和图片讲故事一直是他工作方式的一部分。使用地图来组织他的故事帮助他在反复改进他的产品以使其可行的过程中牢记他的客户、用户和他们的旅程。

Eric used lots of tools and techniques along the way. But telling stories using words and pictures was always part of the way he worked. Using a map to organize his stories helped him keep his customers, users, and their journey in mind as he iteratively improved his product to viable.

我喜欢用产品发现这个词来描述我们在这个阶段真正做的事情。我们的目标不是建造东西;相反,它是为了了解我们是否在构建正确的东西。碰巧,构建一些东西放在客户面前是了解我们是否正在构建正确的东西的最佳方式之一。我借用了Marty Cagan对发现的定义。[ 6 ]我对发现的定义包括精益创业实践、精益用户体验实践、设计思维实践和大量其他想法。我在发现期间所做的事情不断发展。但目标保持不变:尽快了解我是否正在构建正确的东西。

I like using the term product discovery to describe what we’re really doing at this stage. Our goal isn’t to get something built; rather, it is to learn if we’re building the right thing. It just so happens that building something to put in front of customers is one of the best ways to learn if we’re building the right thing. I borrow my definition of discovery from Marty Cagan.[6] And my definition of discovery includes Lean Startup practice, Lean User Experience practice, Design Thinking practice, and loads of other ideas. And what I do during discovery continues to evolve. But the goal stays the same: to learn as fast as possible whether I’m building the right thing.

真正减少你的实验

Really Minimize Your Experiments

如果我们认识到我们的目标是学习,那么我们就可以最大限度地减少我们构建的内容,而只专注于构建我们需要学习的内容。如果你做得很好,这意味着你早期构建的东西可能还没有准备好生产。事实上,如果是这样,你可能做得太多了。

If we recognize that our goal is to learn, then we can minimize what we build and focus on building only what we need to learn. If you’re doing this well, it means that what you build early may not be production ready. In fact, if it is, you’ve likely done too much.

举个例子:当我是一家为大型连锁零售商构建软件的公司的产品负责人时,我知道我的产品需要在后端的大型 Oracle 数据库上运行。但是数据库人员有时让我很难共事。他们想仔细检查我所做的每一个改变。有时简单的更改需要一周或更长时间。这让我的团队和我的速度放慢了太多。数据库人员的担忧是有道理的,因为所有其他应用程序都依赖于该数据库。打破它对每个人来说都是有风险的。但是他们有一个运行良好的流程来评估和更改数据库——只是花了很长时间。

Here’s an example: when I was a product owner for a company that built software for large, chain retailers, I knew my products needed to run on a big Oracle database on the backend. But the database guys were sometimes a pain for me to work with. They wanted to scrutinize every change I made. Sometimes simple changes would take a week or more. That slowed down my team and me too much. The database guys’ concerns made sense, since all the other applications depended on that database. Breaking it was really risky for everyone. But they had a well-oiled process for evaluating and making database changes—it just took a long time.

对我来说,风险最大的部分是确保我的产品是正确的。因此,我们使用简单的内存数据库构建了软件的早期版本。当然,它们无法扩展,而且我们永远无法向大量普通用户发布我们的早期版本。但是我们早期的最小可行产品实验(当时我们没有这么称呼它们)允许我们用一小部分客户测试想法并且仍然使用真实数据。在与客户进行多次迭代并找到我们认为可行的解决方案之后,我们将更改数据库并将我们的应用程序关闭内存数据库。数据库人员也喜欢我们,因为他们知道当我们做出改变时,我们相信他们是正确的。

The riskiest part for me was making sure my product was right. So we built early versions of software using simple, in-memory databases. Of course, they wouldn’t scale, and we could never release our early versions to a large general audience. But our early minimum viable product experiments (we didn’t call them that then) allowed us to test ideas with a small subset of customers and still use real data. After several iterations with customers, and after we found a solution we believed would work, we’d then make the database changes and switch our application off the in-memory database. The database guys liked us too, because they knew that when we made changes, we were confident they were the right ones.

让我们回顾一下

Let’s Recap

加里使用地图摆脱了扁平积压陷阱,看到了他的产品的大局,然后真正开始关注它是为谁服务的以及它应该是什么。

Gary used a map to get out of the flat-backlog trap and see the big picture of his product, and then to really start focusing on who it was for and what it should be.

Globo.com 的团队使用地图来协调跨多个团队的大计划,并切出他们认为可行的解决方案的一部分工作。

The teams at Globo.com used a map to coordinate a big plan across multiple teams and slice out a subset of work they believed would be a viable solution.

Eric 使用地图将不太可行的版本分割成最小可行产品实验,这使他能够迭代地找到可行的东西。

Eric used a map to slice out less-than-viable releases into minimum viable product experiments that allowed him to iteratively find what would be viable.

最后一个挑战似乎困扰着软件开发,那就是按时完成。假设您确信自己拥有应该构建的东西。并假设其他人依赖它在特定日期上线。几个世纪以来,艺术家们都知道按时完成的秘诀。在下一章中,我们将学习如何将它应用到软件中。

There’s one last challenge that seems to plague software development, and that’s finishing on time. Suppose you’re confident that you have something that should be built. And suppose others are depending on it going live on a specific date. There’s a secret to finishing on time that’s been known by artists for centuries. In the next chapter, we’ll learn how to apply it to software.




[ 6 ] Marty在2007 年的这篇文章中首次描述了他所说的产品发现的含义。后来,他在他的著作《启发:如何创造客户喜爱的产品》(SVPG 出版社)中对此进行了更详细的描述。

[6] Marty first described what he means by product discovery in this 2007 essay. He later describes it in more detail in his book Inspired: How to Create Products Customers Love (SVPG Press).

第 4 章计划按时完成

Chapter 4. Plan to Finish on Time

这是亚伦和迈克。他们为一家名为 Workiva 的公司工作。Workiva 在名为 Wdesk 的平台上制作了一套产品。它为大公司解决了大问题,它是您可能从未听说过的最大的软件即服务公司之一。

This is Aaron and Mike. They work for a company called Workiva. Workiva makes a suite of products on a platform called Wdesk. It solves big problems for large companies, and it’s one of the biggest software-as-a-service companies you’ve likely never heard of.

没有标题的图片

Aaron 和 Mike 看起来很开心,不是吗?但这对于共同努力解决棘手问题的人来说是典型的。还是因为右边那个人手里拿着啤酒?不,不是这样。正是这种解决棘手问题的感觉让他们感到高兴。啤酒只是解决棘手问题的奖励。如果没有因为解决工作中的难题而得到啤酒或同等奖励,你应该找人谈谈。

Aaron and Mike look happy, don’t they? But that’s typical for people who’ve worked together to solve tough problems. Or could it be because the guy on the right has a beer in his hand? Nah, that’s not it. It’s that feeling from having solved a tough problem that’s making them happy. The beer is just a reward for solving the tough problem. If you don’t get beer, or an equivalent reward, for solving tough problems where you work, you should have a talk with someone about that.

Aaron 和 Mike 刚刚完成了几轮产品发现,他们相信他们有一些应该构建并投入生产的东西。

Aaron and Mike have just completed several rounds of product discovery, and they’re confident they have something that should be built and go into production.

对他们来说,发现始于构建他们正在合作的功能理念,以真正了解它是为谁而构建的,以及他们为什么要构建它。然后他们直接与客户交谈,以验证他们对他们今天的工作方式以及真正问题所在的猜测。之后,他们构建了简单的原型。对于 Aaron 和 Mike,他们能够在 Axure 中构建简单的电子原型并与客户一起远程测试它们——首先看看他们是否重视该解决方案,然后确定它是否可用。对于他们正在开发的功能,他们觉得他们不需要在工作软件中制作原型来了解他们需要什么。

For them, discovery started with framing the feature idea they were working with to really understand who it was for and why they were building it. Then they talked directly to customers to validate their guesses about how they were working today and what the real problems were. After that, they built simple prototypes. For Aaron and Mike, they were able to build simple electronic prototypes in Axure and test them with customers remotely—first to see if they valued the solution, and then to be confident that it was usable. For the feature they were working on, they didn’t feel like they needed to prototype in working software to learn what they needed.

在使用简单原型进行多次迭代后,他们终于确信自己拥有值得构建的东西。这听起来工作量很大,但他们在大约三天内就完成了。他们的最后一步是创建积压工作和交付该功能的计划。这就是他们在图片中的计划。这是个好计划。这就是他们快乐的原因。

After multiple iterations with simple prototypes, they finally felt confident they had something worth building. That may sound like a lot of work, but they did it all in about three days. Their last step was to create a backlog and a plan for delivering the feature. That’s their plan in the picture. It’s a good plan. And that’s why they’re happy.

请务必注意,这张地图并不是关于整个产品,它只是关于他们添加到现有产品的一项功能。这就是为什么它比第 1 章中的 Gary或 Globo.com 团队的小。我告诉你这些是因为有些人错误地认为他们需要映射整个产品来做一个小的改变,他们以此作为不映射的理由。

It’s important to note that this map isn’t about a whole product, it’s just about a feature they’re adding to an existing product. That’s why it’s smaller than Gary’s in Chapter 1, or that of the Globo.com teams. I’m telling you this because some people mistakenly believe they need to map their whole product to make a small change, and they use that as a reason not to map.

仅映射支持对话所需的内容。

Map only what you need to support your conversation.

告诉团队

Tell It to the Team

为了构建这个新功能,这两个人需要与他们的团队建立共识。他们的团队需要能够指出问题和改进的可能性,并估计需要多长时间。这就是他们制作这张最终地图的目的。他们用它来讲述这个功能的故事——从用户的角度一步一步地讲。注意到注入地图的印刷屏幕了吗?他们在浏览地图时指着屏幕并突出显示细节,以便听众可以更好地设想解决方案。迪斯尼使用故事板浏览电影的人对这些人一无所知。

To build this new feature, these two guys will need to build shared understanding with their team. Their team needs to be able to point out problems and possibilities for improvement, and to estimate how long it’s going to take. That’s what they built this final map for. They used it to tell the feature’s story—step by step, from the user’s perspective. Notice the printed screens injected into the map? They pointed at screens and highlighted details while walking through the map so those listening could better envision the solution. The people at Disney who walk through movies using a storyboard have nothing on these guys.

没有标题的图片

当团队成员询问为什么屏幕会如此运行时,他们会讲述他们尝试过的变体以及用户的行为方式的故事。当团队询问有关输入数据或提交信息时到底发生了什么的详细问题时,这些人已经考虑过并可以回答。或者,当他们不知道时,他们会与团队讨论想法,并在模型中的原型或便签纸上做笔记。他们甚至为他们没有想到的细节添加了一些便利贴,但团队做到了。Aaron 告诉我,团队发现了几个他和 Mike 永远不会发现的技术依赖关系。

When team members asked why the screen behaves as it does, they had stories to tell about variations they’d tried, and how users behaved. When the team asked detailed questions about exactly what happens when data is entered, or information submitted, these guys had given it thought and could answer. Or, when they didn’t know, they discussed ideas with the team, and made notes on the prototypes or sticky notes in the model. They even added a couple of sticky notes for details they hadn’t thought of, but the team did. Aaron told me that the team spotted several technical dependencies that he and Mike would never have found.

良好估算的秘诀

The Secret to Good Estimation

任何长期从事软件开发游戏的人都知道,最大的挑战之一是估计开发实际需要多长时间。我将让您了解良好估算的最保守秘密之一:

Anyone who’s been in the software development game for any length of time knows that one of the biggest challenges is estimating how long development will actually take. I’m going to let you in on one of the best-kept secrets of good estimation:

最好的估计来自真正了解他们正在估计的内容的开发人员。

The best estimates come from developers who really understand what they’re estimating.

有许多方法有望提供更准确的估计。我不打算在这里介绍其中任何一个。但我告诉你,如果构建软件的人彼此之间以及设想它的人之间没有共同的理解,那么它们都行不通。

There are lots of methods that promise to give more accurate estimates. I’m not going to cover any of those here. But I will tell you none of them work if the people building the software don’t have shared understanding with one another, and with those who envisioned it.

没有标题的图片

建立共同的理解不应该成为估算的秘密。所以你现在应该去告诉别人。

Building shared understanding shouldn’t be a well-kept secret about estimation. So you should go tell someone else right now.

计划逐个构建

Plan to Build Piece by Piece

Workiva 的团队在这一点上不能真正摆脱建设。他们不能像 Globo.com 在第 2 章中所做的那样把事情删掉,因为他们已经证实他们需要这一切。当他们制作原型时,他们能够削减很多并验证他们的解决方案对客户仍然有价值。但是,当你看他们的地图时,它被切成三片。

The team at Workiva can’t really get away with building less at this point. They can’t do what Globo.com did in Chapter 2 and cut things away, because they’ve already validated that they need it all. When they were prototyping, they were able to cut away a lot and validate that their solution was still valuable to customers. But, when you look at their map, it’s cut into three slices.

“他们为什么要关心?” 你可能会问。客户想要的三分之一有点像交付一辆跑车的三分之一。没有人能驾驶它。但 Mike 是产品负责人。在确定一个好的解决方案后,他不会走开。现在他的角色变了,有点像电影里的导演。拍摄每个场景时,他都必须在那里。他必须决定哪些场景应该先拍,哪些场景最后拍。他知道最终整部电影需要组合在一起,看起来像一个连贯的整体。

“Why would they care?” you might ask. A third of what the customers want is sort of like delivering a third of a sports car. No one could drive it. But Mike is the product owner. He doesn’t get to walk away after he’s identified a good solution. His role changes now, and he’s a bit more like a director in a movie. He’s got to be there as every scene is shot. And he’s got to decide which scenes should be shot first, and which scenes get shot last. He knows that in the end the entire movie needs to come together and look like one coherent whole.

因此,迈克与他的团队一起制定了一个发展计划。这就是他们所做的:他们将地图分成三个横切切片。

So Mike worked with his team to create a development plan. This is what they did: they sliced their map into three, crosscutting slices.

第一个切片贯穿整个功能。一旦他们构建了所有这些部分,他们就可以看到端到端的功能。它不会在所有需要的情况下工作,如果他们以这种方式运送给用户,那些用户会嚎叫。但是 Mike 和他的团队将能够看到软件端到端地运行。他们将能够将真实数据放入其中以查看其性能如何,并且他们可以对其应用一些自动化测试工具以查看其扩展性如何。他们可以学到很多关于以后可能会给他们带来麻烦的技术风险。他们可以更有信心继续前进,他们将能够按时发布。或者,至少他们会发现会减慢他们速度的不可预见的挑战。我将第一个切片称为功能性行走骨架——这是我从 Alistair Cockburn 那里借来的一个术语。我听说其他人称其为“钢丝”或“曳光弹”。

The first slice cuts all the way through the functionality. Once they build all those pieces, they can see the functionality working from end to end. It wouldn’t work in all the situations it needs to, and if they shipped to users this way, those users would howl. But Mike and his team will be able to see the software running end to end. They’ll be able to put real data in it to see how well it performs, and they could apply some automated testing tools to it to see how well it scales. They can learn a lot about the technical risks that might cause them trouble later on. They can be more confident going forward that they will be able to release on time. Or, at least they’ll spot the unforeseen challenges that would slow them down. I call this first slice a functional walking skeleton—a term I borrowed from Alistair Cockburn. I’ve heard others call this a “steel thread” or a “tracer bullet.”

他们将在第二个切片上分层以构建功能——使其更接近可发布。在此过程中,他们可能会学到一些他们无法预料的事情。他们可能忽略了此功能应具有的一些特征——原型中未探索的更细微之处。他们可能已经发现系统没有按照他们预期的方式运行,需要做一些额外的工作才能获得他们想要的速度。这些是“可预测的不可预测的”——一个与唐纳德拉姆斯菲尔德的“未知的未知数”密切相关的概念。不要假装它们不存在。你知道他们这样做。

They’ll layer on the second slice to build up the functionality—to get it closer to releasable. Along the way, they’re likely to learn some things they couldn’t predict. They may have overlooked some characteristics this feature should have—finer points that weren’t explored in the prototype. They may have found that the system just doesn’t perform the way they expected and some extra work will need to be done to get the speed they want out of it. These are the “predictably unpredictables”—a concept closely related to Donald Rumsfeld’s “unknown unknowns.” Don’t pretend they don’t exist. You know they do.

最后,他们将在第三个切片上分层以优化特征,使其尽可能完美。他们还会添加一些不可预知的东西。

Finally, they’ll layer on the third slice to refine the feature, to make it as polished as it can be. They’ll also add in some of those unpredictable things.

没有标题的图片

不要释放每一片

Don’t Release Each Slice

这些切片中的每一个都不是对客户和用户的发布:它是团队成员用来停下来评估他们所处位置的里程碑。从用户和客户的角度来看,它是不完整的,所以不要让自己感到尴尬。

Each of these slices isn’t a release to customers and users: it’s a milestone the team members will use to stop and take stock of where they are. From a user and customer perspective it’s incomplete, so save yourselves the embarrassment.

Mike 和 Aaron 的团队估计此功能大约需要两个月的工作。像埃里克一样,他们使用两周的冲刺,所以他们需要四次冲刺。我猜他们本可以做四片,每个冲刺一个,但他们并没有那样想。你也不应该。将这些切片想象成三个不同的桶,每个桶都有不同的学习目标。决定他们将在时机成熟时进入哪些冲刺或迭代。

Mike and Aaron’s team estimated this feature to be about two months’ worth of work. Like Eric, they used two-week sprints, so it would take them four sprints. I guess they could have made four slices, one for each sprint, but they weren’t thinking of it that way. And you shouldn’t, either. Think of these slices as three different buckets with different learning goals for each. Decide which sprints or iterations they’ll go into when the time comes.

良好估计的另一个秘密

The Other Secret to Good Estimation

有一件事似乎是秘密,但实际上不应该是秘密,那就是估计是……估计的。访问 Web 并找到任何矛盾修辞法列表。我相信您会在那里找到这个术语:准确估计。如果我们确切地知道事情需要多长时间,那么我们就不会称其为估算,对吗?

One thing that seems to be a secret, but really shouldn’t be, is that estimates are…estimated. Hit the Web and find any list of oxymorons. I’m confident you’ll find this term there: accurate estimate. If we knew exactly how long things would take, then we wouldn’t have called it an estimate, would we?

但是,如果您构建少量软件,您可以非常确定的一件事是构建它们花费了多长时间。这就是所谓的测量,而且要准确得多。

But if you build little bits of software, one thing you can be pretty sure of is how long they took to build. That’s called measurement, and that’s quite a bit more accurate.

好吧,这是另一个秘密:你测量得越频繁,你的预测就越好。如果你每天上下班,我怀疑你很擅长预测需要多长时间。如果我问你到达大致相同区域的不同地址需要多长时间,我敢打赌你可以预测在正负 10 分钟内通勤需要多长时间。这就是估算的工作方式。

Ok, so here’s the other secret: the more frequently you measure, the better you get at predicting. If you commute to work every day, I suspect you’re pretty good at predicting how long it’ll take. If I asked you how long it’d take to get to a different address in roughly the same area, I’ll bet you could predict how long commuting there would take within plus or minus about 10 minutes. That’s the way estimation works.

通过将大事物分割成小事物,我们可以获得更多的衡量机会。当然,这有一些微妙之处,但作为一般原则,如果您有更多关于构建类似事物所花费时间的示例,您将获得更好的预测。

By slicing large things into small things, we get more opportunities to measure. Of course, there’s some subtlety to this, but as a general principle, you’ll get better predictions if you’ve got more examples of how long similar things have taken to build.

作为产品负责人,Mike 最终要按时发布此功能。他是一个优秀的产品负责人,所以他帮助他的小团队中的每个人也对这个目标负起责任。他将这些早期估计视为他的交付预算。

As a product owner, Mike is ultimately on the hook for getting this feature released on time. He’s a good product owner, so he helps everyone in his small team take some ownership of that goal too. He treats these early estimates as his delivery budget.

管理您的预算

Manage Your Budget

Mike 和 Aaron 与他们早期信任的开发人员一起工作,以获得初步的时间估算。他们将其视为预算他们积极管理它。

Mike and Aaron worked together with developers they trust early on to get an initial time estimate. They treat it as a budget. And they actively manage it.

对于团队构建的每一小块,他们可以衡量构建该块所花费的时间。他们将自己建造的东西视为超出预算的开支。他们可能会发现他们已经完成了预算时间的一半,但只完成了构建功能的三分之一。当然,他们没有预料到这一点,但现在他们意识到了,并且可以为此做点什么。他们可以从他们正在开发的其他功能中借用一些预算。或者,他们可以对不会显着改变用户获得的好处的功能进行小的更改。或者他们可以面对现实,看看他们能做些什么来改变他们承诺交付给的人的期望。

With every small piece the team builds, they can measure how long that piece took to build. They treat what they’ve built as spending against their budget. They may find that they’re halfway through their budgeted time, but only a third of the way through building the feature. Certainly they didn’t expect that, but now they’re aware and they can do something about it. They could borrow some budget from other features they’re working on. Or there may be small changes they could make to the feature that won’t substantially change the benefit users get. Or they could just face the music and see what they can do to change expectations with the people they’ve promised delivery to.

根据情况的严重程度,他们可能都需要更多啤酒。

Depending on how bad it is, they may all need more beer.

在制定发展战略时,他们会尽早解决可能超出预算的问题。这些都是有风险的事情。与整个团队的对话有助于发现他们。

When slicing out a development strategy, they’ll look to tackle the things that may blow their budget as early as possible. Those are the risky things. And it’s conversations with the whole team that help spot them.

达芬奇会做什么?

What Would da Vinci Do?

我经常这样问自己。好吧,我真的不知道。但也许我应该。

I often ask myself that. OK, I don’t really. But maybe I should.

Mike 和 Aaron 所做的是遵循艺术家使用的及时完成的​​策略。这是我多年来一直使用的软件。而且,当我第一次在 Globo.com 遇到我的朋友时,我发现他们正在使用它,因为正如我之前提到的,如果他们迟到了为奥运会提供很酷的新互动内容,奥林匹克委员会将不会重新安排奥运会. 我想这个策略是您甚至不假思索地经常使用的策略。

What Mike and Aaron have done is to follow a strategy used by artists to finish in time. It’s one I’ve used for years with software. And, when I first met my friends at Globo.com, I found it’s one they use, because as I mentioned before, if they’re late with cool, new interactive stuff for the Olympics, the Olympic committee won’t reschedule the Olympics. I’ll guess this strategy is one you even use routinely, without thinking.

让我先解释一下达芬奇不做什么。但是,不幸的是,这往往是人们构建软件确实尝试做的事情。

Let me first explain what da Vinci doesn’t do. But, unfortunately, it’s too often what people building software do try to do.

假设你是达芬奇,你想创作一幅画,并且正在按照一个天真的软件团队的方式工作。[ 7 ]你可以从你认为在你的脑海中清晰的画面开始。然后你把这幅画分成几个部分。假设你有五天的时间来画这幅画。每天你都会画更多的部分。在第五天结束时,Huzzah!——你完成了!什么可以更简单?

Suppose you were da Vinci, and you wanted to create a painting and were working the way a naïve software team does.[7] You might start with what you believe is a clear vision of the painting in your mind. Then you break up the painting into its parts. Let’s say you had five days to paint this painting. Every day you’d paint more parts. At the end of day five, huzzah!—you’re done! What could be simpler?

没有标题的图片

只是,它不是那样工作的——至少对艺术家来说不是这样。这种创造事物的方式假设我们的愿景是正确和准确的。它还假设了一些关于创作者的技能以及她在不在上下文中看到它们的情况下精确定义零件的能力。如果你在软件开发中这样做,它被称为增量策略这就是瓦匠砌墙的方式。如果每一块都像砖一样有规则的大小和明确的定义,它就会起作用。

Only, it doesn’t work like that—at least not for artists. This way of creating things assumes our vision is correct and accurate. It also assumes something about the skill of the creator and her ability to precisely define parts without seeing them in context. If you do this in software development, it’s called an incremental strategy. It’s the way a bricklayer might build a wall. And it works if each piece is as regularly sized and well defined as a brick.

当我小时候画画的时候,我就掉进了这个陷阱。我经常画某种动物,然后从头开始。我会一直画到完美为止,然后继续画身体的其余部分——腿、尾巴等等。当我接近完成时,我可以看到我的动物的比例有点不对劲。头部对于身体的其他部分来说太大或太小。腿似乎扭曲成一个奇怪的角度。而这个生物的姿势似乎有点僵硬。至少,这是我作为一个才华横溢的六岁孩子的看法——所有六岁的孩子都是才华横溢的艺术家。

When I used to draw as a kid, I fell into this trap. I’d often be drawing some sort of animal and start with the head. I’d work on that ‘til it was perfect, then continue to draw the rest of the body—legs, tail, and so on. By the time I got close to done, I could see that the proportions of my animal had gotten a bit off. The head was too big, or too small for the rest of the body. The legs seem to be twisted at an odd angle. And the pose of the creature just seemed a bit stiff. At least, that was my perspective as a talented six-year-old—and all six-year-olds are talented artists.

晚年我才知道先画整个构图对我有好处。从那里我可以得到正确的比例,并改变生物的姿势。我什至可能会重新考虑我要画什么。

It was later in life that I learned I’d benefit from sketching the whole composition first. From there I could get proportions right, and make changes to the pose of the creature. I’d maybe even reconsider what I was going to draw.

我没有和达芬奇在一起,但我希望他也做了同样的事情。

I wasn’t there with da Vinci, but I expect he did something much the same.

没有标题的图片

甚至达芬奇也可能承认他的远见并不完美,并且他在创作这幅画时会学到一些东西。第一天,我想他先画了构图草图,或者可能画了淡淡的底色。我可以想象他此时正在改变构图。“嘿,我认为微笑将是一个重要的部分。我会把她的手从嘴里移开。背景中的那些山脉……太多了。”

Even da Vinci would probably acknowledge that his vision wasn’t perfect, and that he’d learn something as he was creating the painting. On day one, I imagine he first sketched the composition, or maybe did a light underpainting. I can imagine him at this point making changes to the composition. “Hey, I think the smile is going to be an important part. I’ll move her hand away from her mouth. And those mountains in the background…too much.”

到周中,达芬奇为这幅画添加了许多颜色和形式,但他仍在不断地进行修改。到周末时,他知道自己的时间不多了,所以他所有的精力都转移到了完善这幅画上。有人想知道蒙娜丽莎没有眉毛是故意的选择,还是达芬奇只是没时间添加一个新的、完全精致的特征。

By midweek, da Vinci is adding lots of color and form to the painting, but he’s still making changes as he goes. By the end of the week, he knows he’s running out of time, so all his effort shifts to refining the painting. One wonders if the Mona Lisa missing her eyebrows was a deliberate choice, or if da Vinci simply ran out of time to add a new, fully refined feature.

伟大的艺术永远不会完成,只会被抛弃。— 列奥纳多·达·芬奇

Great art is never finished, only abandoned. — Leonardo da Vinci

这句话出自达芬奇之手,它表达了我们可以永远继续添加和完善的概念,但在某些时候,我们需要交付产品。而且,如果达芬奇的作品和许多其他艺术家的作品都是很好的例子,那么我们——欣赏作品的人——不知道它被遗弃了。对我们来说,它看起来已经完成了。

That quote is attributed to da Vinci, and it speaks to the notion that we could continue to add and refine forever, but that, at some point, we need to deliver the product. And, if da Vinci’s work and that of lots of other artists are good examples, we—the people who appreciate the work—have no idea it was abandoned. To us, it looks finished.

迭代和增量

Iterative AND Incremental

艺术家或作家就是这样工作的。事实上,制作早报或晚报的人就是这样工作的。创造现场戏剧的人就是这样工作的。任何必须在截止日期前交付并边做边学的人都认可这种策略。

An artist or author works this way. In fact, the people who put together the morning paper or evening news work this way. The people who create live theater work this way. Anyone who must deliver on a deadline, and learn as he goes, recognizes this strategy.

使用迭代思维来评估和更改您已经完成的工作。

Use iterative thinking to evaluate and make changes to what you’ve already made.

在软件开发中,迭代有两个含义。从过程的角度来看,就是一遍又一遍地重复同样的过程。这就是为什么敏捷开发中使用的开发时间盒通常被称为迭代的原因。但是当你使用这个术语来描述你正在用你构建的软件做什么时,它意味着评估和改变它。在构建之后更改软件通常被视为失败。在这里,糟糕的需求或范围蔓延等术语被用来谴责那些决定构建什么的人。但我们都知道,改变是学习的必然结果。

In software development, iterate has two meanings. From a process perspective, it means to repeat the same process over and over. That’s why the development time-box used in Agile development is often called an iteration. But when you use this term to describe what you’re doing with the software you build, it means to evaluate and change it. And changing software after it’s built is too often seen as a failure. It’s where terms like bad requirements or scope creep get used to reprimand the people who made decisions about what to build. But we all know that change is a necessary result of learning.

使用增量思维进行添加。

Use incremental thinking to make additions.

不幸的是,我们很容易陷入迭代的漩涡中。所以我们必须密切关注日历并不断增加更多内容。艺术家不仅通过在绘画中添加全新的东西来添加更多,而且还通过构建已经添加的东西来添加更多。

Unfortunately, we can easily get trapped in the whirling eddies of iteration. So we’ve got to keep our eye on the calendar and keep incrementally adding more. The artist adds more not only by adding whole new things to a painting, but also by building up things that were already added.

您可以通过首先创建一个没有任何额外功能的简单版本来在软件中做同样的事情。您可能会认为这是您的草图。使用简单版本后,您可以通过向其添加更多功能来构建它。随着时间的推移,它逐渐成为您和其他人最初设想的最终版本。如果事情进展顺利,它会构建出与您最初预想不同的东西,但会更好,因为它会受益于您所学到的知识。

You might do the same things in software by first creating a simple version of functionality without any extras. You might think of this as your sketch. After using the simple version, you’d build it up by adding more functionality to it. Over time, it builds up to be the finished version you and others may have originally envisioned. If things go really well, it builds up to something different than you originally envisioned, but better because it benefits from what you’ve learned.

开局、中局和残局策略

Opening-, Mid-, and Endgame Strategy

这可能会让你有点头疼,但我会在这里混合一些比喻。在创建软件时,我个人依赖基于国际象棋比喻的策略。我是一个几乎不会下棋的废棋手,所以如果我用错了这个比喻,你不准给我写信和纠正我。无论产品或功能发布多小,我都喜欢将我的发布积压分为三组:

This may hurt your head a bit, but I’m going to mix some metaphors here. I personally rely on a strategy based on a chess metaphor when creating software. I’m a crap chess player who barely knows how to play the game, so if I’m misusing the metaphor, you’re not allowed to write me and correct me. No matter how small the product or feature release, I prefer to slice my release backlog into three groups:

开场比赛
Opening game
关注贯穿整个产品的基本功能或用户步骤。专注于技术上具有挑战性或风险的事情。跳过用户可能做的可选事情。在发布之前跳过您知道需要的复杂业务规则。构建足以让产品端到端运行的产品。
Focus on the essential features or user steps that cross through the entire product. Focus on things that are technically challenging or risky. Skip the optional things users might do. Skip the sophisticated business rules you know you’ll need before you can release. Build just enough to see the product working end-to-end.
中局
Midgame
填写和完善功能。添加支持用户可能采取的可选步骤的内容。实施那些严格的业务规则。如果您正确地完成了开场游戏,您将能够开始端到端地测试产品的性能、可扩展性和可用性等方面。这些都是难以消化的质量问题。我们需要意识到它们,并不断测试它们。
Fill in and round out features. Add in stuff that supports optional steps users might take. Implement those tough business rules. If you’ve done your opening game stuff right, you’ll be able to start testing the product end-to-end for things like performance, scalability, and usability. Those are all the quality concerns that are hard to bake in. We need to be aware of them, and constantly test them.
结束游戏
Endgame
完善您的版本。让它更性感,使用起来更高效。由于您现在可以将它与真实数据一起大规模使用,因此您可以在这里找到很难从原型中看到的改进机会。在这里,您将获得可以应用的用户的反馈。
Refine your release. Make it sexier, and more efficient to use. Since you can use it now with real data and at scale, here’s where you’ll find improvement opportunities that were hard to see from a prototype. It’s here that you’ll have feedback from users you’ll be able to apply.

在地图上切出您的发展战略

Slice Out Your Development Strategy in a Map

如果您已经发现了您认为对客户和用户而言可行的首次发布,那么作为一个团队一起工作,将首次公开发布再次分成开场游戏、中期游戏和结束游戏故事。创建产品的团队最擅长识别风险和学习机会所在的位置。他们会对共同制定的计划产生强烈的主人翁意识。

If you’ve discovered what you believe is a viable first release to customers and users, work together as a team to slice that first public release again into opening game, mid game, and endgame stories. The team creating the product is best at identifying where the risks and opportunities to learn are. They’ll feel the strongest ownership over the plan they create together.

没有标题的图片

这就是 Aaron 和 Mike 在他们整个开发团队的帮助下所做的。再看看他们多开心。

That’s what Aaron and Mike did with the help of their whole development team. Look again at how happy they are.

一切都与风险有关

It’s All About Risk

第 3 章中,埃里克不得不应对识别错误产品的风险。他采用了一种拆分发布的策略,使他能够将整个产品呈现在客户面前。

In Chapter 3, Eric had to deal with the risk of identifying the wrong product. He used a strategy of slicing out releases that allowed him to put whole products in front of customers.

在本章中,Aaron 和 Mike 专注于技术风险,这些风险可能会破坏他们的交付计划或导致该功能的成本远远超过他们的预期。他们不会在每个周期结束时向客户和用户展示他们最终得到的结果,因为他们已经知道这还不够。但是他们会自己和他们的团队认真认真地审视它,并使用他们学到的知识来安全地引导此功能的开发。

In this chapter, Aaron and Mike are focused on technical risk, the things that might blow their delivery schedule or cause the feature to cost much more than they expected. They won’t show what they end up with at the end of every cycle to customers and users because they already know it’s not sufficient. But they’ll take a good, hard look at it themselves and with their team, and use what they learn to safely steer the development of this feature.

这很微妙,但您可能已经在第 2 章中发现,Eric 进行了两次为期两周的冲刺,以构建他的下一个最小可行产品实验。他必须决定在第一个冲刺中构建哪些东西,在第二个冲刺中构建哪些东西。他用这种思维来做出那些决定。他和他的团队把有风险的部分放在首位——Eric 或他的团队希望尽快看到工作的部分,以便他们可以在将其呈现给客户之前纠正路线。

It’s subtle, but you might have caught in Chapter 2 that Eric was taking two two-week sprints to build his next minimum viable product experiment. And he had to decide which things to build in the first sprint, and which to build in the second sprint. He used this kind of thinking to make those decisions. He and his team put the risky bits first—the parts that Eric or his team wanted to see working sooner so that they could course-correct before they put it in front of their customers.

怎么办?

Now What?

您已经看到了为不同目的构建和使用地图的四个非常好的示例。我们将在后面的章节中探讨更多使用地图的方法。但在你走得太远之前,我想向你展示我最喜欢的教别人如何绘制地图的技巧。我保证,如果您尝试一下,从那一刻起您就会像专家一样绘制地图。

You’ve seen four pretty good examples of building and using maps for different purposes. There are a lot more ways to use maps that we’ll explore in later chapters. But before you get too far, I want to show you my favorite trick for teaching others how to map. I promise if you try it, you’ll map like an expert from that moment on.

让我们从第 5 章开始。

Let’s pick up there in Chapter 5.




[ 7 ]我从 John Armitage 2004 年的论文“Are Agile Methods Good for Design?”中得到了这个简单可视化的想法。约翰以这种方式描述了接近用户体验设计。我建议我们也将这个比喻带入我们的构建方式中。

[7] I got the idea for this simple visualization from John Armitage’s 2004 paper “Are Agile Methods Good for Design?” John describes approaching user experience design this way. I’m suggesting we carry the metaphor into the way we build as well.

第 5 章你已经知道怎么做了

Chapter 5. You Already Know How

如果您认为创建故事地图是复杂的、神秘的,或者以任何方式难以做到,那么现在让我向您保证,事实并非如此。事实上,您已经了解用于创建地图的所有基本概念。现在让我们来看一个取自日常生活的例子。而且,为了简单起见,我们将用你的生命。在此过程中,我将为您已经了解的那些重要概念命名。

If you think that creating a story map is complicated, or mystical, or in any way hard to do, let me assure you right now that it’s not. In fact, you’re already wired to understand all the basic concepts used to create a map. Let’s work through an example right now, taken from everyday life. And, to make it simple, we’ll use your life. Along the way I’ll give some names to those important concepts you already understand.

拿起便签本和一支笔,跟我来。别担心——慢慢来。我会等。

Grab a pad of sticky notes and a pen, and follow along with me. Don’t worry—take your time. I’ll wait.

准备好?

Ready?

1. 一次一步写出你的故事

1. Write Out Your Story a Step at a Time

闭上眼睛,回想你今早醒来的那一刻。你今天早上确实醒了,对吧?你记得做的第一件事是什么?现在,睁开眼睛,把它写在便利贴上。我会和你一起写。我的第一张便利贴上写着,“打瞌睡。” 不幸的是,通常是这样。在糟糕的早晨,我可能不得不打两三下。

Close your eyes, and think back to the moment you woke up this morning. You did wake up this morning, right? What’s the first thing you recall doing? Now, open your eyes, and write it down on a sticky note. I’ll write along with you. My first sticky note says, “Hit snooze.” Unfortunately, it usually does. On bad mornings I may have to hit it two or three times.

现在,撕掉那张胶粘物,把它放在你面前的桌子上。然后,想想你接下来做的事情。知道了?现在,把它写在下一张便利贴上,撕下,贴在第一张便利贴旁边。然后继续。我接下来的几张即时贴上写着,“关掉闹钟”和“跌跌撞撞地去洗手间”。

Now, peel off that sticky and put it on the table in front of you. Then, think of the next thing you did. Got it? Now, write it on the next sticky, peel it off, and place it next to the first one. Then keep going. My next couple of stickies say, “Turn off alarm” and “Stumble to the bathroom.”

继续写便签,直到你准备好工作,或者无论你今天在做什么。我通常以“上车”结束,开始开车上班。我预计您需要三四分钟才能写完所有便签。

Keep writing sticky notes until you’ve gotten ready for work, or whatever you’re doing today. I usually end with “Get into my car” to start my drive for work. I expect it’ll take you three or four minutes to write all your stickies.

没有标题的图片

任务就是我们所做的

Tasks Are What We Do

看看你写的所有便利贴。注意到它们都是如何以动词开头的吗?好吧,几乎所有的人。这些简短的动词短语,如“Take a shower”和“Brush teeth”是任务,意思是我们为了达到目标而做的事情。当我们描述人们使用我们的软件为实现他们的目标而执行的任务时,我们将它们称为用户任务这是构建好的故事地图最重要的概念——更不用说编写和讲述好故事了。您会发现故事地图中几乎所有关于人们使用您的软件做什么的便签都使用这些简短的动词短语。

Take a look at all the sticky notes you wrote. Notice how all of them start with a verb? Well, almost all of them. These short verb phrases like “Take a shower” and “Brush teeth” are tasks, which just means something we do in order to reach a goal. When we describe the tasks people using our software do in order to reach their goals, we’ll call them user tasks. It’s the most important concept to building good story maps—not to mention writing and telling good stories. You’ll find that almost all the sticky notes in story maps about what people do using your software use these short verb phrases.

现在停在这里一分钟,想想那是多么容易。我让你写下你做了什么,你的脑子里自然而然地出现了任务。我认为最重要的概念是最自然的,这很酷。

Now stop here for a minute and think about how easy that was. I asked you to write down what you did, and naturally out of your brain tasks came out. I think it’s pretty cool that the most important concept is the most natural.

不要太在意任务这个词。如果您是项目经理,您会注意到项目计划中充满了任务。如果您一直在敏捷开发中使用故事,您就会知道规划工作涉及编写大量的开发和测试任务。如果你既不是项目经理也不是软件开发人员,当你使用任务这个词时要小心,因为其他人可能会认为你指的是他们通常想到的那种任务,他们会告诉你你用错了.

Don’t get too hung up on that word task. If you’re a project manager, you’ve noticed project plans are full of tasks. If you’ve been using stories in Agile development, you know that planning work involves writing a bunch of development and testing tasks. If you’re neither a project manager nor a software developer, watch out when you use the word task because those other people might think you mean the kind of tasks they usually think about, and they’ll tell you you’re using it wrong.

用户任务是故事地图的基本构建块。

User tasks are the basic building blocks of a story map.

现在,数一数你写下的任务数。

Now, count the number of tasks you wrote down.

大多数人写在 15 到 25 之间。如果你写得更多,那就太棒了。如果你写得少,伙计,你的生活就会很简单。我希望我能在早上这么快就做好准备。但是您可能想回顾一下您的列表,看看是否有任何您跳过的内容。

Most people write somewhere between 15 and 25. If you wrote more, that’s fabulous. If you wrote less, man, you’ve got a simple life. I wish I could get ready in the morning that quickly. But you may want to look back at your list and see if there’s anything you skipped writing down.

我的任务与你的不同

My Tasks Are Different Than Yours

我相信这不会让您感到惊讶,但人与人之间是不同的。您会在他们选择做事的方式上看到这些差异。

I’m sure this doesn’t come as a surprise to you, but people are different from one another. You’ll see these differences expressed in the way they choose to do things.

例如,有些人几乎每天早上都有锻炼的动力和自律。如果你写了几个与锻炼相关的任务,那你太棒了!我自己仍在努力。

For instance, some people have both the motivation and self-discipline to exercise almost every morning. If you wrote a couple of tasks related to exercise, you rock! I’m still working on that myself.

有些人只是因为他们居住的家庭而承担了更多的责任。如果你有孩子,我保证你会写下一些没有孩子的人没有的任务。如果你有一只狗,你可能会有一两个任务专门用来照顾这只狗。

Some people simply have more responsibilities because of the household they live in. If you’ve got kids, I promise you wrote down several tasks that people without kids didn’t. If you have a dog, you may have a task or two dedicated to taking care of the dog.

当您考虑使用您的软件的人时,请记住这一点。他们在使用它时可能有不同的目标。他们可能会在不同的环境中使用它,迫使他们考虑其他人或事物。

Keep that in mind when you’re thinking about people using your software. They may have different goals when using it. They may use it in different contexts that force them to take into account other people or things.

没有标题的图片

我只是更注重细节

I’m Just More Detail-Oriented

在这个练习中,有些人只是写了比其他人更多的细节。他们可能会说“做早餐”之类的东西,而不是写“把面包放进烤面包机”、“倒一杯果汁”,或者,如果你是我妻子的话,“在冰沙里加羽衣甘蓝”,这是其中一个我真的很讨厌她做的任务。

In this exercise, some people just write a lot more details than others. They might take something like “Make breakfast” and instead write “Put bread in the toaster,” “Pour a glass of juice,” or, if you’re my wife, “Add kale to the smoothie,” which is one of the tasks I really hate her doing.

任务就像石头。如果你拿一块大石头用锤子敲它,它会碎成一堆小石头。那些较小的岩石仍然是岩石。任务也是一样。现在我不知道什么时候石头大到可以称为巨石,什么时候小到可以称为鹅卵石,但是有一种很酷的方法可以区分大任务和小任务。

Tasks are like rocks. If you take a big rock and hit it with a hammer, it’ll break into a bunch of smaller ones. Those smaller rocks are still rocks. It’s the same thing with tasks. Now I don’t know when a rock is big enough to be called a boulder, or small enough to be called a pebble, but there’s a cool way to tell a big task from a small task.

我的朋友 Alistair Cockburn 描述了目标水平的概念在他的书Writing Effective Use Cases (Addison-Wesley Professional) 中。别担心,我们不会开始编写用例。只是当我们谈论人类行为时,这个概念真的很有用。

My friend Alistair Cockburn described the goal level concept in his book Writing Effective Use Cases (Addison-Wesley Professional). Don’t worry, we’re not going to start writing use cases. It’s just that the concept is really useful when we’re talking about human behavior.

阿利斯泰尔使用海拔比喻,海平面在中间,其他一切要么高于海平面,要么低于海平面。海平面任务是我们希望在有意停下来做其他事情之前完成的任务。您是否在任务列表中写下了“洗澡”?这是一项海平面任务,因为您不会在淋浴进行到一半时想,伙计,这场淋浴正在拖延。我想我会喝杯咖啡,稍后再洗完澡Alistair 称这些功能级任务并用一点海浪来注释它们。但我只是称它们为任务。

Alistair uses an altitude metaphor where sea level is in the middle, and everything else is either above or below sea level. A sea-level task is one we’d expect to complete before intentionally stopping to do something else. Did you write “Take a shower” in your list of tasks? That’s a sea-level task because you don’t get halfway through your shower and think, Man, this shower is dragging on. I think I’ll grab a cup of coffee and finish this shower later. Alistair calls these functional-level tasks and annotates them with a little ocean wave. But I’ll just call them tasks.

没有标题的图片

像“洗澡”这样的任务会分解成许多更小的子任务,比如“调节水温”和“洗头”,如果你是我妻子,还有一些涉及丝瓜去角质的东西。请记住,人是不同的,您会在他们处理任务的方式上看到行为差异。阿利斯泰尔用一条小鱼来注释这些,因为它们在海底。

Tasks like “Take a shower” break down into lots of smaller subtasks like “Adjust water temperature” and “Wash hair,” and, if you’re my wife, something involving an exfoliating loofah thing. Remember, people are different, and you’ll see behavior differences in the way they approach tasks. Alistair annotates these with a little fish because they’re below the ocean.

最后,我们可以将一堆任务汇总成一个摘​​要级任务淋浴、刮胡子、刷牙,以及早上起床后所做的所有其他事情都可以归结为一项摘要任务。不过,我不确定我会怎么称呼它。“收拾干净了吗?” “早上沐浴?” 沐浴是一个愚蠢的词。不要用那个。

Finally, we could roll up a bunch of tasks into a summary-level task. Taking a shower, shaving, brushing teeth, and all that other stuff you do in the morning after you get out of bed could roll up into a summary task. I’m not sure what I’d call it, though. “Getting cleaned up?” “Morning ablutions?” Ablutions is a silly word. Don’t use that.

使用目标级别的概念来帮助您聚合小任务或分解大任务。

Use the goal-level concept to help you aggregate small tasks or decompose large tasks.

2.组织你的故事

2. Organize Your Story

如果您还没有这样做,请按照从左到右的顺序组织您的任务,先做的在左边,后来做的在右边。

If you haven’t done this already, organize your tasks in a left-to-right flow with what you did first on the left, and what you did later on the right.

试着讲一个故事,指着第一个便利贴说,“首先我做了这个,”然后指着下一个便利贴说,“然后,我做了这个。” 现在继续从左向右移动并讲述您的故事。你可以看到每个便利贴都是一个步骤,隐藏在每个便利贴之间的是漂亮的连词“……然后我……”

Try telling a story by pointing at the first sticky note and saying, “First I did this,” and then pointing to the next sticky and saying, “then, I did this.” Now keep going moving from left to right and telling your story. You can see that each sticky note is a step, and hidden in between each sticky note is the nifty little conjunction phrase “…and then I…”

我将这种从左到右的顺序称为叙事流程,它是“讲故事顺序”的一种奇特说法。我们将把这整个东西称为地图并且叙事流是它的从左到右的轴。

I’ll call this left-to-right order the narrative flow, which is a fancy way of saying “storytelling order.” We’ll call this whole thing a map and that narrative flow is its left-to-right axis.

没有标题的图片

哇,我的流量变得非常广泛。我开始堆叠同时发生的事情。当我布置流程时,我发现我已经错过了一些细节,我正在尝试确定它们是否重要。

Wow, my flow got pretty wide. I started stacking things that happen in and around the same time. As I lay out the flow, I see I already missed a few details, and I’m trying to decide if they matter.

地图使用叙事流程从左到右组织:您讲述故事的顺序。

Maps are organized left-to-right using a narrative flow: the order in which you’d tell the story.

填写缺失的详细信息

Fill in Missing Details

这种便签排列的妙处在于它让我们看到了整个大故事。查看以叙事流程组织的故事可以让您更轻松地看到故事中缺失的部分。

The cool thing about this arrangement of sticky notes is that it allows us to see the whole big story. Seeing the story organized in a narrative flow allows you to more easily see the parts of the story that are missing.

回顾你的成长地图,寻找你可能错过的步骤。

Look back at your growing map and look for steps you might have missed.

我又加了几个。我决定不写下海平面以下的许多细节。如果我这样做了,就会有数百个便利贴。

I added just a few more. There’s lots of details that are below sea level that I’ve decided to not write down. If I did, there’d be hundreds of stickies.

3.探索另类故事

3. Explore Alternative Stories

到目前为止,这是显而易见的,对吧?学习这个几乎不值得你浪费纸张。但是等等,它会变得有趣。

So far this is dead obvious, right? Learning this was hardly worth the paper you’re wasting. But wait, it’s about to get interesting.

花点时间想想你昨天早上做了什么。如果你昨天早上做的事情和今天早上做的不一样,把它们写下来并添加到你的地图上。

Take a minute and think about what you did yesterday morning. If there are different things you did yesterday morning than you did this morning, write them down and add them to your map.

想想事情出错的早晨。如果没有热水怎么办?你当时做了什么?如果你没有牛奶或麦片或任何你通常早餐吃的东西怎么办?如果您的女儿因为忘记完成今天要交的家庭作业而陷入恐慌怎么办,这是我家时不时发生的事情。然后呢?为您要执行的操作编写任务并将其添加到地图中。

Think of mornings when things went wrong. What if there was no hot water? What did you do then? What if you were out of milk or cereal or whatever you normally eat for breakfast? What if your daughter flew into a panic because she forgot to do her homework that’s due today, which is what happens in my house every once in a while. Then what? Write tasks for what you’d do and add them to the map.

现在,想想你理想中的早晨。什么会让你的早晨变得完美?对我来说,就是做点运动,享受一顿丰盛的早餐,同时继续阅读。但那样我就得早点起床,停止打瞌睡。

Now, think about your ideal morning. What would make your morning perfect? For me, it would be getting some exercise and enjoying a long breakfast while I catch up on some reading. But then I’d have to get up a lot earlier and stop hitting snooze.

另请注意,您需要将一些任务放在一列中,这既是为了节省空间,也是因为它们看起来与您通常可能执行的其他任务相似。例如,您可能会发现自己有做一顿非常棒的早餐的任务,您可以将这些任务与通常做的快速早餐的任务一起放在一个列中。

Notice also that you’ll want to put some tasks in a column, both to save space and because they seem similar to other tasks you might normally do. For example, you might find that you’ve got tasks for making a really great breakfast that you can put in a column along with the tasks for making the quick breakfast you normally make.

没有标题的图片

我的朋友 David Hussman 称之为“玩什么”,你可能还记得第 2章和第 3章中的一个短语。不幸的是,我们可以玩很长时间的 What-About 并使这张地图变大。我在我的地图上添加了一些东西,专门用于我希望做的事情,比如锻炼身体或在早餐时做一些放松的阅读。我还添加了一些通常在早上发生的更常见的替代方案。

My friend David Hussman calls this “playing What-About,” a phrase you might remember from Chapter 2 and Chapter 3. Unfortunately, we could play What-About for a long time and make this map huge. I added a few more things to my map specifically for things I wish I’d done, like exercising or doing a bit of relaxing reading during breakfast. I also added a few more common alternatives that often happen in the morning.

详细信息、备选方案、变体和例外情况填充在地图的主体中。

Details, alternatives, variations, and exceptions fill in the body of a map.

保持流动

Keep the Flow

请注意,当您开始添加这些新任务时,您可能不得不重新组织您的叙述流程。我知道做到了。例如,我需要在起床和洗澡之间进行锻炼。而且我必须添加“穿上运动服”,这与淋浴后的“穿好衣服”步骤不同。

Notice that when you start to add these new tasks, you’ll likely have to reorganize your narrative flow. I know I did. For instance, I’d need to slip that exercise thing in between getting up and taking a shower. And I’d have to add in “Put on exercise clothes,” which isn’t the same as the “Get dressed” step after taking a shower.

如果你放松并把事情放在看起来自然的地方,你会发现一个感觉正确的叙事流程。当你现在讲述你的故事时,你会发现你可以用很多不同的方式来讲述它。您可以讲述典型的日常故事、美妙的日常故事以及发生一两次紧急情况的故事——所有这些都可以通过在您从左到右讲故事时指向不同的即时贴来完成。尝试使用其他一些连词将您的任务粘合在一起。你可能会说,“我通常这样做,但有时我会这样做”或“我这样做,或这样做,然后再这样做。” (我希望你用你实际做的来填写这个词因为我从这里看不到你指的是什么。)

If you relax and put things where it seems natural, you’ll find a narrative flow that feels right. When you tell your story now, you’ll find that you can tell it a bunch of different ways. You can tell the typical day story, the fabulous day story, and the story that has an emergency or two—all by pointing at different stickies as you talk through it from left to right. Try using some other conjunctions to glue your tasks together. You might say, “I usually do this, but sometimes I do this” or “I do this, or this, and then this.” (I’m expecting you to fill in the word this with what you actually do, because I can’t see what you’re pointing at from here.)

小时候,有一套很受欢迎的儿童读物系列,叫做《选择你自己的冒险》. 也许你还记得他们。这个想法是,你会读到一个部分的末尾,然后有几个关于故事主人公接下来会做什么的选择。每个选择之后是一个页码。做出选择后,您将转到该页面并从那里继续阅读故事。说实话,我从来都不喜欢那些书。无论我做出什么选择,我似乎总是在同一个地方结束;似乎从来没有足够的选择来进行一次真正伟大的冒险。地图有点像那样,但更好。通过地图的方式几乎是无限的——如果你考虑真实的人可能使用软件产品来实现他们的目标的方式,这实际上是非常准确的。

When I was a kid, there was a popular series of children’s books called Choose Your Own Adventure. Maybe you remember them. The idea was that you’d read to the end of a section and then be given a couple of choices about what the hero of the story would do next. After each choice was a page number. Once you made your choice, you would turn to that page and continue reading the story from there. Truthfully, I was never a fan of those books. I always seemed to end up at the same place no matter what choice I made; there never seemed to be enough choices to make a really great adventure. The map works a little like that, except better. The number of ways through a map is almost limitless—which, if you’re thinking about the way real people might use a software product to meet their goals, is actually pretty accurate.

如果你想让事情变得真正具有挑战性,请与几个与你一起工作的人一起做这个练习。关于与你一起工作的人,你会学到比你想知道的更多的东西,而且你会发现每个人都同意的叙述流程会很有趣。我所说的“乐趣”是指“争论”。总是有人在洗澡前吃早餐,有人在洗澡后吃早餐。有一个关于刷牙的大争论——你是在早餐前刷牙还是早餐后刷牙,还是两者都刷牙?

If you want to make things really challenging, do this exercise with a couple of people you work with. You’ll learn more than you ever wanted to know about the people you work with, and you’ll have a bit of fun finding a narrative flow everyone agrees on. By “fun,” I mean “argument.” There are always people who eat breakfast before showering, and some who eat after. There’s the great tooth-brushing debate—do you brush before or after breakfast, or both?

放松。

Relax.

如果你在争论,这可能意味着这无关紧要。例如,将早餐放在淋浴之前或之后是个人喜好问题。选择与您一起工作的小组最常见的内容。你会发现人们不会为重要的事情争论不休。例如,将“穿好衣服”放在“洗澡”之后不仅仅是偏好问题。反过来做会导致穿着湿衣服上班。

If you’re arguing, it likely means that it doesn’t matter. For instance, putting breakfast before or after taking a shower is a matter of preference. Go with what’s most common for the group you’re working with. You’ll find people won’t argue about things that do matter. For example, putting “Get dressed” after “Take a shower” isn’t just a matter of preference. Doing it the other way around results in showing up to work wearing wet clothes.

4.提炼你的地图来制作主干

4. Distill Your Map to Make a Backbone

到目前为止,您的地图应该看起来很宽,如果您已经探索了很多选项,可能会有点深。它可能有 30 个或更多任务。它看起来应该像某种奇怪动物的脊椎和肋骨。

By now, your map should be looking pretty wide, and if you’ve explored lots of options, maybe a little deep. It’ll likely have 30 or more tasks. It should look like the spine and ribs of a weird animal.

如果你退后一步,从左到右查看你的地图,你会发现有一堆故事似乎是连在一起的——例如,你在浴室里做的所有准备工作,或者所有这些事情在厨房里做早餐,或者检查天气,拿一件外套,把你的笔记本电脑或其他你在离开家之前需要的东西装在你的包里。你能看到那些似乎在一起帮助你实现更大目标的任务群吗?

If you step back a bit and look across your map from left to right, you’ll find there are bunches of stories that seem to go together—for instance, all those things you do in the bathroom to get ready, or all those things in the kitchen to make breakfast, or that junk you do to check the weather, grab a coat, and load your bag with your laptop or other stuff you’ll need before leaving the house. Can you see those clusters of tasks that seem to go together to help you reach a bigger goal?

在这些相似的便签簇中的每一个上方,放一张不同颜色的便签。在上面写一个简短的动词短语,提炼出它下面的所有任务。

Above each of these clusters of similar stickies, put a different colored sticky note. Write a short verb phrase on it that distills all the tasks underneath it.

如果你没有不同颜色的便利贴,我会告诉你一个秘密。每包便利贴都有两种形状!将便利贴旋转 45 度,噗,你得到了一个很酷的菱形。如果您想使粘性看起来不同,请使用它。

If you don’t have a different color of sticky note, I’ll let you in on a secret. Every package of sticky notes comes with two shapes! Rotate a sticky note 45 degrees and, poof, you’ve got a cool diamond shape. Use that if you want to make a sticky look different.

这些具有更高目标级别任务的便签称为活动活动组织了由相似的人在相似的时间完成的一系列任务,以达到特定的目标。当您阅读地图顶部的活动时,它们也处于叙述流程中。一排便利贴是地图的主干。如果您有一张地图,里面有很多便签纸并且您想分享它,一个好的开始方法是讲一个高层次的故事。只需阅读地图的主干部分,每个活动之间都有“……然后他们……”连词。

These sticky notes with a higher goal-level task are called activities. Activities organize a bunch of tasks done by similar people at similar times in order to reach a particular goal. When you read the activities across the top of the map, they’re in a narrative flow, too. The row of stickies is the backbone of the map. If you’ve got a map with lots of stickies in it and you wanted to share it, a good way to start is by telling a high-level story. Just read the backbone of the map, with the “…and then they…” conjunction between each activity.

活动聚合了针对共同目标的任务。

Activities aggregate tasks directed at a common goal.

没有标题的图片

这是我的成长地图,其中添加了活动以赋予地图主干。它使阅读和查找内容变得更容易,至少对我而言。这让我更容易真正了解早上发生的事情。

Here’s my growing map with activities added to give the map a backbone. It makes it easier to read and find things, at least for me. And it makes it easier to really get the big picture of what’s going on in my morning.

活动和高级任务构成了故事地图的支柱。

Activities and high-level tasks form the backbone of a story map.

活动似乎不像任务那样有共同语言。例如,您在离开家之前做的那件事叫什么?你收拾包包、查找购物清单、查看天气并在需要时带上雨伞的那种东西?我可以称之为“收拾垃圾”。你可能会称它为不同的东西。

Activities don’t seem to have common language the way tasks do. For instance, what do you call that thing you do before leaving the house? That thing where you gather up your bag, find a shopping list, check the weather, and grab an umbrella if you need it? I could call it “gathering up my junk.” You might call it something different.

当你为你的产品和你的客户构建这些时,你会想要他们怎么称呼它。

When you build these for your products and your customers, you’ll want to call it what they call it.

5. 切分有助于你达到特定结果的任务

5. Slice Out Tasks That Help You Reach a Specific Outcome

现在,这是非常酷的部分 — 您可以使用地图来帮助您想象未发生的事情的部分。

Now, here’s the really cool part—the part where you get to use the map to help you imagine something that didn’t happen.

如果您查看已构建的地图,您可能会在左侧边缘的某处看到“打瞌睡”或“关闭闹钟”。想象一下,今天早上你可以跳过那个。你可以跳过它,因为昨晚你忘记设置闹钟了。你猛地睁开眼睛,看了看你的时钟,你发现你需要在几分钟内到达某个地方。你真的来晚了!不要惊慌——我们只是在假装。

If you look at the map you’ve built, you’ll probably see “Hit snooze” or “Turn off alarm” somewhere on the left edge. Imagine that this morning you can skip that one. You can skip it because last night you forgot to set your alarm. Your eyes shot open and looked at your clock and you saw you needed to be somewhere in just a few minutes. You’re really late! Don’t panic—we’re just pretending.

在便利贴上写下“几分钟后出门”,并将其放在地图左侧靠近顶部的位置。现在,想象一条线从左到右穿过地图的中间——有点像腰带。现在,如果您不想在几分钟内完成离开的目标,请将所有任务移至该线下方。不要将活动向下移动,即使它们下面没有任务。让活动中没有任务可以让你表明你今天早上不会达到那个目标。

Write “Get out the door in a few minutes” on a sticky and place it to the left of the map near the top. Now, imagine a line slicing through the middle of the map left to right—kinda like a belt. Now, move all the tasks below that line if you wouldn’t do them to reach the goal of getting out in a few minutes. Don’t move the activities down, even if there are no tasks left under them. Having the activity with no tasks in it lets you show that you aren’t going to hit that goal this morning.

您可能只剩下顶部切片中的几个任务。现在返回流程并填写缺少的任务以及如果您迟到会做的任务。例如,你可能通常会洗澡,但当你迟到时,你会添加诸如“往脸上泼水”或“用毛巾清洗我身体特别臭的部位”之类的任务。当与一组开发人员一起做这个活动时,我经常看到任务“应用额外的除臭剂”。我不是在评判。我只是说。

You’ll likely be left with just a few tasks in the top slice. Now go back through the flow and fill in tasks that are missing and that you would do if you were late. For example, you might normally take a shower, but when you’re late you instead add in tasks like “Splash water on face” or “Use a washcloth to wash the particularly stinky parts of my body.” When doing this activity with a group of developers, I often see the task “Apply extra deodorant.” I’m not judging. I’m just saying.

没有标题的图片

这是我的切片地图,用于查找我需要在几分钟内出门的任务。

Here’s my map sliced to find the tasks I’ll need to get out the door in a few minutes.

您可以通过将不同的目标挂在左侧来尝试这个技巧。比如“度过一个最奢华的早晨”或“去度个两周的假期”。您会发现叙事流程保持相当持久,但您需要添加或删除任务以帮助您实现不同的目标。

You can try this trick by thinking of different goals to hang on the left side. Like “Have the most luxurious morning ever” or “Leave for a two-week vacation.” You’ll find the narrative flow stays pretty durable, but that you’ll need to add or remove tasks to help you reach that different goal.

使用切片来识别与特定结果相关的所有任务和详细信息。

Use slices to identify all the tasks and details relevant to a specific outcome.

就是这样!你已经学会了所有重要的概念

That’s It! You’ve Learned All the Important Concepts

那真的很容易,不是吗?在构建这张地图时,您了解到:

That was really easy, wasn’t it? As you built this map you learned that:

  • 任务是描述人们做什么的简短动词短语。
  • Tasks are short verb phrases that describe what people do.
  • 任务有不同的目标级别
  • Tasks have different goal levels.
  • 地图中的任务按从左到右的叙述流程排列。
  • Tasks in a map are arranged in a left-to-right narrative flow.
  • 地图的深度包含变化和替代任务。
  • The depth of a map contains variations and alternative tasks.
  • 任务按地图顶部的 活动进行组织。
  • Tasks are organized by activities across the top of the map.
  • 活动构成地图的主干
  • Activities form the backbone of the map.
  • 您可以对地图进行切片以确定达到特定结果所需的任务。
  • You can slice the map to identify the tasks you’ll need to reach a specific outcome.

在家里或工作中试试这个

Do Try This at Home, or at Work

现在,我很确定你们中的很多人只是在阅读,而不是在阅读时真正映射。别以为我没注意到。但是,如果您是那些没有在早上绘制地图的懒鬼之一,请向我保证您会尝试一下。毫无疑问,这是我最喜欢的教授这些基本绘图概念的方式。如果您是在您的组织中第一次尝试映射,请召集一小群人并完成此练习。你们都将学习基础知识。而且您将能够很好地绘制任何东西

Now, I’m pretty sure a great number of you were just reading along and not really mapping as you read. Don’t think I didn’t notice. But if you’re one of those slackers who didn’t map your morning, promise me you will try it. It’s hands down my favorite way of teaching these basic mapping concepts. If you’re trying out mapping for the first time in your organization, get a small group of people together and run through this exercise. You’ll all learn the basics. And you’ll be well on your way to being able to map anything.

这是现在的地图,而不是以后的地图

It’s a Now Map, Not a Later Map

我怀疑你们中的一些人注意到了这一点,但是您刚刚创建的地图与前四章中创建的地图有根本的区别。Gary、Globo.com、Eric、Mike 和 Aaron 创建的地图都设想了用户在未来将如何使用他们的产品——稍后,在产品交付之后。他们编写了他们想象中人们在产品中所做的任务和活动。但你创建的地图是关于你现在做事方式的地图——事实上,今天早上。而且,事实证明,两者的概念是相同的。所以请放心,我没有浪费你的时间。

I suspect a few of you caught this, but the map you just created has a fundamental difference from the maps created in the first four chapters. The maps Gary, Globo.com, Eric, and Mike and Aaron created all imagine how users will use their products in the future—later, after the product is delivered. They wrote tasks and activities that they imagined people doing in the product. But the map you created is a map about the way you do things now—this morning, as a matter of fact. And, as it turns out, the concepts are the same in both. So be relieved I haven’t wasted your time.

没有标题的图片

“现在的故事地图”的一个很酷的事情是你可以构建它们来更好地了解人们今天的工作方式。你这样做只是为了了解你今天早上是如何准备的。如果您返回并向地图添加其他内容,您可以了解更多信息。简单的添加是:

One of the cool things about “now story maps” is that you can build them to better understand how people work today. You just did this to learn how you got ready this morning. You can learn even more if you go back and add other things to the map. The easy things to add are:

痛苦
Pains
不起作用的东西,人们讨厌的部分
Things that don’t work, parts people hate
欢乐或奖励
Joys or rewards
有趣的事情,值得做的事情
The fun things, the things that make it worth doing
问题
Questions
人们为什么这样做?他们这样做时发生了什么?
Why do people do this? What’s going on when they do?
想法
Ideas
人们可以做的事情,或者我们可以建立的事情,可以消除痛苦,或者让快乐变得更好
Things people could do, or that we could build that would take away pain, or make the joys even better

用户体验社区中的许多人多年来一直在构建这些以更好地了解他们的用户。有时它们被称为旅程地图,但它们的基本思想相同。

Lots of people in the user experience community have been building these for years to better understand their users. Sometimes they’re called journey maps, but they’re the same basic idea.

试试这个真的

Try This for Real

2000 年代初,我在一家名为 Tomax 的小型产品公司领导团队。我们为实体零售商构建了软件——那些我们在把所有时间都花在网上之前经常去的购物场所。我们接待了一位经营大型油漆和室内装饰连锁店的新客户。现在,我们对零售业以及在销售点销售商品和管理库存的用户了解颇多,但有些事情我们并不知道,这些事情是油漆和装饰店特有的。例如,我们不知道如何销售定制有色油漆或定制百叶窗。我们必须快速学习。

In the early 2000s, I led a team at a small product company called Tomax. We built software for brick-and-mortar retailers—those shopping places we used to go to before spending all our time online. We’d taken on a new customer that ran a large chain of paint and interior decoration stores. Now, we knew quite a bit about retail—and about the users who sold things at point of sale and managed inventory—but there were some things we didn’t know that were specific to paint and decor stores. For instance, we didn’t know how to sell custom-tinted paint or custom blinds. And we had to learn fast.

没有标题的图片

为了帮助我们学习,我们请求这三位女士的帮助。他们不是软件人。他们是为需要我们软件的公司工作的室内装饰师。从他们那里,我们了解了销售定制百叶窗的来龙去脉。为了快速学习,我们让他们回想上次销售定制百叶窗的情景。我们要求他们写下他们所做的一切——从客户联系他们的那一刻起,直到百叶窗安装完毕并且客户满意为止。现在这听起来应该很熟悉,因为我们要求他们做与您刚才一样的事情来绘制您的早晨——而且几乎是一样的。他们可以说出他们为销售定制百叶窗所做的工作,就像您可以说出自己的名字一样容易早上做准备。而且,当我们组织他们的任务时,我们都知道没有任何一种方法可以做事,他们每个人做事的方式不同或顺序不同。如果您与一小群不同的人一起尝试早上起床地图,您会看到同样的事情。

To help us learn, we asked for the help of these three ladies. They’re not software people. They’re interior decorators working for the company that wanted our software. From them we learned the ins and outs of selling custom blinds. So that we could learn quickly, we asked them to think back to the last time they sold custom blinds. We asked them to write down everything they did—from the moment a customer contacted them, until the moment the blinds were installed and their customer was happy. Now that should sound familiar, because we asked them to do the same thing you just did to map your morning—and it went pretty much the same way. They could name what they did to sell custom blinds as easily as you could name what you did to get ready in the morning. And, when we organized their tasks, we all learned that there wasn’t any one way to do things, that they each did things differently or in a different order. You’ll see the same thing if you try the getting-up-in-the-morning map with a small group of different people.

从这个简单的讲故事和绘图活动中,我们都对他们现在的工作方式建立了共同的理解。正是从这里开始,我们可以开始将这张地图转化为他们需要在我们以后创建的软件中做的事情。

From this simple storytelling and mapping activity, we all built shared understanding of how they worked now. It was from here that we could begin to translate this map into the things they’d need to do in the software we’d create later.

使用软件更难

With Software It’s Harder

我不会骗你的。如果您是一名软件专家,您可能需要一段时间才能停止谈论功能和屏幕,并开始编写简短的动词短语来说明人们真正想做的事情。保持练习。你会明白的。

I won’t lie to you. If you’re a software professional, it may take you a while to stop talking about features and screens, and to start writing short verb phrases that say what people are really trying to do. Keep practicing. You’ll get it.

如果您不确切地知道您的用户是谁、她想要完成什么或她如何去做,这将非常困难。可悲的是,在这种情况下尝试构建地图只会指出您不知道的内容。如果那是你所在的地方,那么你将需要更多地了解人们以及他们所做的事情。更好的是,直接与他们合作创建地图。

This will be really hard if you don’t know exactly who your user is, what she’s trying to accomplish, or how she goes about it. Sadly, trying to build a map in this situation will just point out what you don’t know. If that’s where you are, then you’ll need to learn more about people and what they do. Better yet, work with them directly to create a map.

地图只是一个开始

The Map Is Just the Beginning

绘制地图可以帮助您看到全局,只见树木不见森林。这是故事地图的最大好处之一。但是,如果您是负责建造森林的人,则需要一次建造一棵树。您已经了解了让故事发挥作用的两个最重要的因素:

Building a map helps you see the big picture, to see the forest for the trees. That’s one of the biggest benefits of story mapping. But if you’re the one responsible for building the forest, you’ll need to do it one tree at a time. You’ve already learned the two most important things that make stories work:

  • 用文字和图片讲故事来建立共同的理解。
  • Use storytelling with words and pictures to build shared understanding.
  • 不要只是谈论构建什么:谈论谁将使用它以及为什么这样你可以最小化输出并最大化结果。
  • Don’t just talk about what to build: talk about who will use it and why so you can minimize output and maximize outcome.

记住这些事情,随着你的前进,一切都会水到渠成。

Keep these things in mind, and everything will fall into place as you go forward.

现在是我们讨论“逐树”使用故事的一些策略的时候了,因为很多地方都可能出错,而且要很好地使用故事,您还需要了解一些其他事项。

It’s time we talked about some of the tactics for using stories “tree by tree,” because a lot can go wrong, and there are a few more things you need to know to use stories well.




[ 8 ]封面故事是戴夫·格雷 (Dave Gray) 等人在《游戏风暴》( Gamestorming ) 一书中发现的众多优秀实践之一。(奥莱利)。

[8] Cover Story is one of the many great practices found in the book Gamestorming by Dave Gray, et al. (O’Reilly).

第 6 章关于故事的真实故事

Chapter 6. The Real Story About Stories

故事地图是一个非常简单的想法。使用简单的地图,您可以与他人一起讲述产品故事,并像您一样查看大图。然后,您将大局剖析以做出良好的规划决策。在这一切之下是敏捷故事的简单概念。

Story mapping is a remarkably simple idea. Using a simple map, you can work with others to tell a product’s story and see the big picture form as you do. Then, you carve up that big picture to make good planning decisions. Underneath all that is the simple concept of Agile stories.

肯特颠覆性的简单想法

Kent’s Disruptively Simple Idea

故事的想法起源于一个名叫肯特贝克的非常聪明的人。上世纪 90 年代后期,Kent 与其他人一起从事软件开发,他注意到软件开发中最大的问题之一源于使用文档来精确描述我们想要的东西(即需求)的传统过程方法。现在你知道问题所在了。不同的人可以阅读同一份文件并想象不同的事物。他们甚至可以在文档上“签字”,相信他们已经达成一致。

The idea of stories originated with a very smart guy by the name of Kent Beck. Kent was working with other people on software development in the late ’90s, and he noticed that one of the biggest problems in software development sprang from the traditional process approach of using documents to describe precisely what we want—that is, the requirements. By now you know the problem with that. Different people can read the same document and imagine different things. They can even “sign off” on the document believing they’re in agreement.

没有标题的图片

后来,当我们深入开发软件时——甚至比这更晚,在软件交付之后——我们才意识到我们在考虑不同的事情。许多人将这种缺乏共同理解的情况称为“糟糕的需求”。

It’s later, when we get into the thick of developing software—or even later than that, after it’s delivered—that we realize we weren’t thinking of the same things. Lots of people call this lack of shared understanding “bad requirements.”

让我在这里发泄一下。我很高兴与许多团队合作。我们经常通过谈论他们面临的最大挑战来开始合作。而且,毫无疑问,我听到最多的是“糟糕的要求”。然后每个人都指着那个文件。文档编写者感觉很糟糕——好像他应该多写或少写,或者使用一些很酷的需求技术。那些签字的人先是难过,然后是义愤填膺。“你肯定没想到我会阅读每一个细节!毕竟,我们已经讨论了好几天了。我只是希望你能理解我说的话。反正我也看不懂你那愚蠢的需求文档。” 构建软件的人感到措手不及。他们糊里糊涂地浏览了那些神秘的文件,但他们构建的东西仍然是错误的。每个人最终都讨厌这份文件。

Let me vent a minute here. I have the pleasure of working with lots of teams. And we often start work together by talking about their biggest challenges. And, hands down, the one I hear most is “bad requirements.” And then everyone points at that document. The document writer feels bad—as if he should have written more, or less, or used some cool requirements technique. Those who signed off feel bad at first, and then indignant. “Surely you didn’t expect I’d read every detail! After all, we talked about this for days. I just expected you’d understood what I said. I can’t understand your silly requirements document anyway.” And the people building the software feel blindsided. They muddled their way through those cryptic documents and what they built was still wrong. Everyone hates the document in the end. Yet we still keep trying to write a better one.

我们可以同时阅读同一份文件,但对它有不同的理解。

We can both read the same document, but have a different understanding of it.

但误解文档只是问题的一半。我们浪费了大量的时间和金钱来构建文档描述的内容,后来才发现真正解决预期问题的方法是非常不同的。你没听错。这些文件往往准确地描述了错误的事情。文档通常会描述我们需要什么,但不会描述我们为什么需要它。如果构建软件的人可以简单地与了解将使用该软件的用户以及他们为什么使用它的人交谈,通常会有一种更具成本效益的方式来取悦这些用户。不说话,我们就永远不知道它。

But misunderstanding the document is only half the problem. We waste lots of time and money building what the document describes, only to find out later that what actually solves the intended problem is something very different. You heard me right. Those documents often accurately describe the wrong thing. Documents usually describe what we need, but not why we need it. If the person building software could simply speak with someone who understood the users who will be using the software and why they’ll be using it, there’s often a more cost-effective way to delight those users. Without talking, we just never know about it.

最好的解决方案来自需要解决问题的人和能够解决问题的人之间的协作。

The best solutions come from collaboration between the people with the problems to solve and the people who can solve them.

肯特的简单想法是阻止它——停止如此努力地编写完美的文档,并聚在一起讲故事故事的名字不是来自它们应该如何编写,而是来自它们应该如何被使用。让我更加激动地重复一遍。现在你应该停止你正在做的任何事情并大声说出来:

Kent’s simple idea was to stop it—to stop working so hard on writing the perfect document, and to get together to tell stories. Stories get their name not from how they’re supposed to be written, but from how they’re supposed to be used. Let me repeat that with more emotion. Right now you should stop whatever you’re doing and say this out loud:

故事的名字来自于它们应该如何被使用,而不是来自于你试图写下的内容。

Stories get their name from how they’re supposed to be used, not from what you’re trying to write down.

肯特的想法很简单。如果我们聚在一起讨论我们正在用软件解决的问题,谁会使用它,为什么,那么我们就可以一起找到解决方案,并在此过程中建立共同的理解。

Kent’s idea was simple. If we get together and talk about the problem we’re solving with software, who’ll use it, and why, then together we can arrive at a solution, and build shared understanding along the way.

简单并不容易

Simple Isn’t Easy

不久前,我开始注意到整个故事有点偏离方向了;也就是说,许多写书、教学和使用书籍的人都专注于写故事的活动。如果每次有人问我如何写好故事时我都能得到一毛钱,我得到的毛钱会比几章前收集到的还要多。

A while back I began to notice that this entire story thing had gone a bit sideways; that is, lots of the people writing books, teaching, and using them focused on the activity of writing stories. If I had a dime for every time I’ve been asked how to write good stories, I’d have even more dimes than I collected a few chapters ago.

我全神贯注于写故事,然后回到肯特,以确保我没有遗漏任何东西。在电子邮件对话过程中,肯特解释了这个想法的来源:

With all the focus on writing stories, I went back to Kent to make sure I wasn’t missing something here. Over the course of an email conversation, Kent explained where the idea came from:

我在想的是用户有时会讲述他们使用的软件所做的很酷的新事物的故事。[例如,] 如果我输入邮政编码,它会自动填写城市和州,而无需我触摸按钮。

我认为这是触发这个想法的例子。如果您可以讲述有关软件功能的故事并在听众的脑海中产生兴趣和愿景,那么为什么不在软件执行之前讲故事呢?

Kent Beck 通过个人电子邮件,2010 年 8 月

What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does. [For example,] if I type in the zip code and it automatically fills in the city and state without me having to touch a button.

I think that was the example that triggered the idea. If you can tell stories about what the software does and generate interest and vision in the listener’s mind, then why not tell stories before the software does it?

Kent Beck via personal email, Aug 2010

所以这个想法是有说服力的,如果你在听众的脑海中产生能量、兴趣和愿景,你就知道你做对了。那很大。而且这听起来比阅读典型的需求文档有趣得多。[ 9 ]

So the idea is telling, and you know you’re doing it right if you’re generating energy, interest, and vision in the listener’s mind. That’s big. And it sounds a lot more fun than reading a typical requirements document.[9]

但是那些开始使用故事进行软件开发的人——以及他们头脑中仍然保留着传统过程模型的人——往往会专注于写作部分。我见过团队用写故事取代他们的传统需求流程,然后在尝试写故事来准确传达应该构建的内容时感到沮丧。如果您现在正在这样做,请停止。

But folks who start using stories for software development—and who still have a traditional process model in their heads—tend to focus on the writing part. I’ve seen teams replace their traditional requirements process with story writing, and then get frustrated trying to write stories to precisely communicate what should be built. If you’re doing that now, stop it.

如果您没有聚在一起就您的故事进行丰富的讨论,那么您就没有真正使用故事。

If you’re not getting together to have rich discussions about your stories, then you’re not really using stories.

罗恩杰弗里斯和 3 C

Ron Jeffries and the 3 Cs

在《Extreme Programming Installed 》一书中,Ron Jeffries 等人。(Addison-Wesley Longman Publishing) 描述最好的故事过程:

In the book Extreme Programming Installed, Ron Jeffries et al. (Addison-Wesley Longman Publishing) describe the story process best:

卡片
Card
在一堆索引卡上写下您希望在软件中看到的内容。
Write what you’d like to see in the software on a bunch of index cards.
对话
Conversation
聚在一起就构建什么软件进行丰富的对话。
Get together and have a rich conversation about what software to build.
确认
Confirmation
共同商定您将如何确认软件已完成。
Together agree on how you’ll confirm that the software is done.

如果这听起来很简单,那是因为它确实如此。请记住,简单并不容易。

If it sounds simple, it’s because it is. Just remember, simple isn’t easy.

没有标题的图片

1.卡片

1. Card

想象一下,您负责与团队合作构建一些软件。尽你所能想象那个软件。然后,针对用户想用产品做的每一件事,写一张卡片。你最终会得到一堆。肯特最初的想法是将它们写在索引卡片上,因为在桌面上整理一堆卡片很容易。更容易确定它们的优先级,或者将它们组织成一个结构,以帮助您看到全局——当然是像故事地图这样的结构。

Imagine you’re responsible for working with a team to get some software built. Imagine that software as best you can. Then, for each thing users want to do with the product, write a card. You’ll end up with a bunch of them. Kent’s original idea was to write them on index cards because it’s easy to organize a bunch of cards on a tabletop. It’s easier to prioritize them, or organize them into a structure that helps you see the big picture—a structure like a story map, of course.

描述整个产品或我们想要对现有产品进行的所有更改的一堆卡片称为产品积压该术语起源于敏捷过程 Scrum。我认识的人曾经说过,“我讨厌积压这个词。我们甚至还没有开始构建软件,听起来我们已经落后了!” 我不确定我对那一堆故事有更好的名字,但如果你能想到一个好的名字,请使用它,并让我知道它是什么。

The bunch of cards that describes the whole product, or all the changes we’d like to make to a product we have, is called a product backlog. That term originated with the Agile process Scrum. Someone I know once said, “I hate that term backlog. We haven’t even started to build software, and it already sounds like we’re behind!” I’m not sure I have a better name for that bunch of stories, but if you can think of a good one, please use it, and let me know what it is.

2.对话

2. Conversation

谈话可能从你描述你的想法开始,倾听的人可能会根据她听到的内容在她的脑海中形成一个想法。因为很难完美地解释事情,而且因为根据我们过去的经验很容易想象出不同的东西,所以听众可能想象出与你不同的东西。但这就是魔法的用武之地。

The conversation might start with you describing what you’re thinking, and the person listening might form an idea in her head based upon what she heard. Because it’s hard to explain things perfectly, and because it’s easy to imagine different things based on our past experience, the listener likely imagined something different than you. But that’s where the magic comes in.

因为这是一次对话,所以听众可以提出问题,来回提问可以纠正这种理解并帮助每个人达成某种共识。

Because this is a conversation, the listener can ask questions and it’s the back and forth that will correct that understanding and help everyone arrive at some shared understanding.

在传统的软件过程中,有需求的人的目标是将它们正确地写下来;对于要构建软件的人来说,就是要正确理解它们。因为这是一个故事驱动的过程,所以你们每个人都有不同的共同目标。你们的目标是共同努力,了解构建软件所要解决的问题,并尽最大努力解决它。最终,您需要就应该构建的内容达成一致,双方都认为这会对产品的用户有所帮助。

In a traditional software process, the goal for the person who had the requirements is to get them written down correctly; and for the person who’s going to build the software, it’s to understand them correctly. Because this is a story-driven process, you each have a different shared goal. Your goal is to work together to understand the problem being solved by building software, and solve it as best you can. Eventually, you’ll need to agree on what you should build that you both believe will help the users of the product.

让我再说一遍,因为这是很重要的一点:

Let me say this again, because it’s an important point:

故事对话是关于共同努力为我们都理解的问题找到最佳解决方案。

Story conversations are about working together to arrive at a best solution to a problem we both understand.

3.确认

3. Confirmation

所有这些谈话都很酷,但我们最终必须构建一些软件——对吧?所以,当我们觉得我们正在汇聚一个好的解决方案时,我们需要开始关注这些问题的答案:

All this talking is cool, but we’ve eventually got to build some software—right? So, when we feel like we’re converging on a good solution, we’ll need to start focusing on the answer to these questions:

如果我们构建我们同意的内容,我们将检查什么以确保我们已经完成?
If we build what we agree to, what will we check to see that we’re done?
这个问题的答案通常是要检查的事项的简短列表。此列表通常称为验收标准故事测试
The answer to this question is usually a short list of things to check. This list is often called acceptance criteria, or story tests.
当稍后在产品评论中证明这一点时,我们将如何做到这一点?
When it comes time to demonstrate this later at a product review, how will we do that?
这个问题的答案往往会暴露出一些漏洞。例如,您可以使软件运行,但要演示它,您需要获得一些实际数据。讨论演示可能会为您的验收标准列表添加更多项目符号。
The answer to this question often reveals some holes. For example, you could make the software work, but to demonstrate it you’ll need to get your hands on some realistic data. Discussing demonstration may add a few more bullets to your list of acceptance criteria.

文字与图片

Words and Pictures

达成这项协议的途径不仅仅是一张牌和大量的挥手。如果对话包含很多内容,例如简单的人物角色、工作流程图、UI 草图和任何其他有助于解释事情的传统软件模型,那么对话会进行得最好。这样,您不必只是挥手——您也可以指指点点。无论我们将什么带入对话,我们都会进行标记、书写、更正和更改。在那次谈话中,我们甚至会当场创造很多东西。使用白板或活动挂图纸。并且在您离开之前不要忘记拍摄一些“假期照片”。您创建的内容的照片将帮助您回忆起难以写下的对话的所有细节。

The path to get to this agreement isn’t just a single card and lots of hand waving. The conversation goes best if it includes lots of things such as simple personas, workflow diagrams, UI sketches, and any other traditional software model that’ll help explain things. That way, you don’t have to just wave hands—you can point a lot, too. Whatever we bring into the conversation we’ll mark up, write on, correct, and change. We’ll even create a lot of things on the spot during that conversation. Use a whiteboard or flipchart paper. And don’t forget to take some “vacation photos” before you leave. Photos of what you’ve created will help you recall all the details of the conversation that would be difficult to write down.

没有标题的图片

好的故事对话有很多文字和图片。

Good story conversations have lots of words and pictures.

没有标题的图片

在谈话中保持你决定的验收标准大而显眼。这个团队使用活动挂图纸边走边记录。

Keep the acceptance criteria you decide on big and visible during the conversation. This team uses flipchart paper to record as they go.

就是这样

That’s It

仅此而已。这是肯特颠覆性的简单想法。而且,如果你这样做,我向你保证它会改变一切。

That’s all there is. That’s Kent’s disruptively simple idea. And, if you do it, I promise you it’ll change everything.

除非没有。

Unless it doesn’t.

对于习惯于以老式方式工作的人来说,这种对话可能会非常糟糕。他们又回到了他们带来东西的人的旧模式,努力工作以准确地向对方传达他想要的东西,而另一个人则努力尝试理解并在对方说的话上打孔. 如果这样持续太久,他们往往会有互相戳洞的感觉,不利于事情的完成。

For people used to working the old-fashioned way, this conversation can go really badly. They fall back into their old patterns of the person bringing in stuff, trying to work hard to communicate exactly what he wants to the other person, and the other person working hard to try to understand and then punch holes in what the other person is saying. If this goes on too long, they often feel like punching holes in each other, which is not conducive to getting things done.

有一些事情要记住,以帮助这些对话进行得更好。令人高兴的是,这就是下一章的内容。

There are some things to keep in mind to help these conversations go better. Happily, that’s what the next chapter is about.




[ 9 ]有一些证据表明,故事中包含的事实比单独呈现的事实更令人难忘——根据心理学家杰罗姆·布鲁纳 (Jerome Bruner) 的说法,令人难忘的程度是后者的 22 倍。

[9] There’s some evidence that a fact wrapped in a story is much more memorable than the fact presented alone—22 times more memorable, according to psychologist Jerome Bruner.

第 7 章讲更好的故事

Chapter 7. Telling Better Stories

故事的想法很简单。也许太简单了。对于很多软件开发人员来说,像这样的对话感觉很陌生……而且有点不舒服。人们经常像往常一样谈论需求。

The idea of stories is simple. Maybe too simple. For lots of people in software development, conversations like these feel very foreign…and a little uncomfortable. And people often revert to talking about requirements like they always used to.

当 Kent Beck 最初描述故事的概念时,他并没有称它们为用户故事他只是称它们为故事——因为那是他希望你讲的。但是在第一本关于极限编程发表了,故事选择了更具描述性的前缀用户,这样我们就可以记住从软件之外的人的角度进行对话。然而,更改名称还不够。

When Kent Beck originally described the idea of stories, he didn’t call them user stories, he just called them stories—because that’s what he hoped you’d be telling. But very soon after the first books on Extreme Programming were published, stories picked up the more descriptive prefix user so that we’d remember to have conversations from the perspective of the people outside the software. Changing the name wasn’t enough, however.

Connextra 的炫酷模板

Connextra’s Cool Template

这是我的朋友雷切尔戴维斯。她手里拿着一张故事卡。

This is my friend Rachel Davies. And she’s holding a story card.

没有标题的图片

1990 年代后期,她在一家名为 Connextra 的公司工作。Conntextra 是极限编程的最早采用者之一,极限编程是故事的来源。当 Connextra 的人们开始使用故事时,他们发现他们遇到了一些常见的问题。在 Connextra 撰写故事的大多数人来自销售和市场营销部门。他们倾向于写下他们需要的功能。但是,当开发人员需要进行对话时,他们需要找到最初的利益相关者并开始良好的对话——包括谁和为什么。仅仅知道功能的名称并不能帮助团队找到合适的人与之交谈或开始正确的讨论。而且,那时候,没有太多关于卡片上可以或应该包含什么的指导。Connextra 的模板随着时间的推移而演变。这不是雷切尔特意发明的。相当,

In the late 1990s she worked for a company called Connextra. Conntextra was one of the earliest adopters of Extreme Programming, the Agile process where stories came from. When the Connextra folks started using stories, they found they ran into some common problems. Most of the people who wrote the stories at Connextra were from sales and marketing. They tended to write down the feature they needed. But, when it came time for developers to have conversations, they needed to find that original stakeholder and get a good conversation started—one that included who and why. Just having the name of the feature wasn’t helping the team find the right people to talk to, or to start the right discussions. And, back then, there wasn’t much guidance about what could or should be on a card. The template evolved over time at Connextra. It wasn’t Rachel’s invention specifically. Rather, it was the entire organization’s desire to build things that mattered.

使用该模板一段时间后,Connextra 的人们想炫耀一下他们很酷的新技巧。他们打印了一堆示例卡片,以在 XPDay 2001(伦敦的一个小型会议)上炫耀。这就是雷切尔手里拿着的东西。这是她的最后一张牌,很可能是现存的最后一张牌,所以这使它成为历史文物。

After using the template for a while, the folks at Connextra wanted to show off their cool new trick. They printed a bunch of example cards to show off at XPDay 2001, a small conference in London. That’s what Rachel is holding. It’s her last card, and might very well be the last card in existence, so that makes it a historical artifact.

没有标题的图片

模板是这样的:

The template goes like this:

作为[用户类型]

我打算做点什么]

这样我就可以[得到一些好处]

As a [type of user]

I want to [do something]

So that I can [get some benefit]

Connextra 的人们使用这个简单的模板来编写他们故事的描述请注意,他们的故事仍然有简短而有用的标题。他们发现,多写一点点来开始讲述故事会迫使他们停下来思考:谁、什么以及为什么。而且,如果他们不知道,他们可能会质疑他们是否应该写这个故事。

The folks at Connextra used this simple template to write the descriptions of their stories. Note that their stories still have short, useful titles. They found that writing this little extra bit to start to tell the story forced them to pause and think about: who, what, and why. And, if they didn’t know, they might question whether they should be writing the story at all.

当他们坐下来讨论故事时,他们会拿起那张卡片,然后阅读描述。这个描述开始了谈话。

When they sat down to have the story conversation, they’d pick up that card and then read that description. That description started the conversation.

使用简单的故事模板开始对话。

Use the simple story template to start conversations.

如果您在故事地图之外拿起一张单独的卡片,模板是启动对话的好方法。请记住,在第 1 章中,Gary 地图正文中的一张卡片上写着“上传图像”。该卡片是“自定义我的促销传单”卡片下的详细信息之一。我在地图卡片上写的是那些简短的动词短语——用户使用我的软件执行的任务。但是当我自己拿起一个时,我将需要在地图中描述的用户大旅程中间拿起故事。我可能会说:

If you’re picking up an individual card outside of a story map, the template is a good way to boot up the conversation. Remember in Chapter 1 that one of the cards in the body of Gary’s map said, “Upload an image.” And that card was one of the details under the card “Customize my promo flyer.” What I write on the cards in a map are those short verb phrases—the tasks the users are performing with my software. But when I pick one up by itself, I’ll need to pick up the story in the middle of the user’s big journey described in the map. I might say:

“作为乐队经理,我想上传一张图片,以便定制我的宣传传单。”

“As a band manager, I want to upload an image so that I can customize my promo flyer.”

这是一个很酷的把戏。我可以找到挂在地图上方的不同用户的卡片,而用户更大的目标往往就在你随时查看的卡片上方的卡片中。

That’s a pretty cool trick. I can find the cards for different users hanging above the map, and the users’ bigger goal is often in the card above the one you’re viewing at any one time.

但请记住——这只是一个话题的开场白。而且,事实上,对话可能会像这样继续:

But remember—it’s just a conversation starter. And, in fact, the conversation might continue like this:

“乐队经理为什么要定制传单?”

“嗯,因为它不会自动在上面放上他乐队的照片,而他希望它放在那里。而且他非常关心原创——他不希望它看起来像其他人的一样。”

“这就说得通了。像乐队经理这样的人把这些照片放在哪里?”

“嗯,他们到处都是,真的。它们可能在本地硬盘上、Flickr 帐户中或网络上的其他地方。”

“嗯……这和我原本想的不一样。我以为他们只是在他们的硬盘上。”

“不,我们采访过的很多人都让他们遍布各地。这有点问题。”

“Why would the band manager want to customize the flyer?”

“Well, because it won’t have his band’s photo on it automatically, and he’d want it to be there. And he cares a lot about being original—he wouldn’t want it to look like everyone else’s.”

“That makes sense. Where do people like band managers keep those photos?”

“Well, they’re all over the place, really. They may be on their local hard drives, in Flickr accounts, or in other places on the Web.”

“Hmm…that’s different than I was originally thinking. I assumed they’d just be on their hard drives.”

“No, lots of the people we’ve talked to have them spread all over the place. It’s kind of a problem.”

事实上,我和加里的很多谈话都是这样进行的。在我们谈话时,我们会在白板上或卡片上写下一些东西。不久之后,我们就会草拟想法。

In fact, a lot of the conversation I had with Gary went like that. As we were talking, we’d write something down on a whiteboard or on the card itself. Before too long we’d be sketching ideas.

您可以看到非常短的模板不足以成为规范。但是,当我们使用该模板开始对话时,我们最终会进行比仅仅谈论文件上传器更丰富的对话。

You can see that the very short template isn’t nearly enough to be the specification. But when we start a conversation using that template, we end up in a much richer conversation than if we’d just talked about a file uploader.

模板僵尸和扫雪机

Template Zombies and the Snowplow

术语模板僵尸来自Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior一书汤姆德马科等人。(多塞特之家)。这个名字说明了一切,但我会给你作者的定义:

The term template zombies comes from the book Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior by Tom DeMarco et al. (Dorset House). The name says it all, but I’ll give you the authors’ definition:

模板僵尸:

项目团队允许其工作由模板驱动,而不是由交付产品所需的思维过程驱动。

Template Zombie:

The project team allows its work to be driven by templates instead of by the thought process necessary to deliver products.

就像那个模板一样简单,它被滥用了很多。我看到人们真的很难在不合适的时候将想法强加到模板中。有关后端服务或安全问题的故事可能具有挑战性。我看到人们从自己的角度写作和思考事情,而不是最终受益者的角度:“作为产品负责人,我希望你构建一个文件上传器,以满足客户的需求。” 诸如此类的讨厌的事情。

As simple as that template is, it gets abused quite a bit. I see people really struggle to force ideas into the template when they just don’t fit. Stories about backend services or security issues can be challenging. I see people writing and thinking about things from their own perspective, not that of the people who ultimately benefit: “as a product owner, I want you to build a file uploader so that the customer requirements are met.” Nasty things like that.

更糟糕的是,模板已经变得如此普遍,并且被普遍教导,以至于有些人认为如果不是以这种形式编写的,就不是一个故事。许多人甚至不再在故事中使用标题,而是在每张卡片上只写下那句长话。想象一下,尝试阅读以这种方式编写的故事列表。想象一下,尝试使用故事地图向某人讲述一个故事,其中每个便签都是这样写的。这对大脑来说很难。

Even worse, the template has become so ubiquitous, and so commonly taught, that there are those who believe that it’s not a story if it’s not written in that form. Many people have even quit using titles on stories and write only that long sentence on every single card. Imagine trying to read through a list of stories written that way. Imagine trying to tell someone a story using a story map where every sticky is written that way. It’s tough on the brain.

这一切都让我很难过。因为故事的真正价值不在于卡片上写的内容。它来自我们讲故事时学到的东西。

All of this makes me sad. Because the real value of stories isn’t what’s written down on the card. It comes from what we learn when we tell the story.

它不需要写在模板中就可以被视为故事。

It doesn’t need to be written in a template to be considered a story.

没有标题的图片

这张照片中的人正在学习滑雪。[ 10 ]如果你曾经学过滑雪,并且有人在教你,你就会做这个人正在做的事情。它被称为扫雪机。在这里,您可以将滑雪板的尖端放在一起并靠在滑雪板的内侧边缘上。当你的脚上夹着两块滑板时,这是控制速度和保持直立的最简单方法。这是我推荐的学习滑雪的方式。但这不是最佳实践,而是最佳学习实践。没有奥林匹克扫雪机比赛。你酷炫的扫雪机姿势不会给斜坡上的任何人留下深刻印象。不过,这没什么好尴尬的。如果人们看到你那样滑雪,他们就会知道你在学习。

The person in this picture is learning to ski.[10] If you’ve ever learned to ski, and someone helpful is teaching you, you’ll do what this person is doing. It’s called a snowplow. It’s where you put the tips of your skis together and lean on the inside edges of your skis. It’s the easiest way to control your speed and stay upright when you’ve got two slippery boards clamped to your feet. It’s the way I’d recommend learning to ski. But it’s not best practice—it’s a best learning practice. There’s no Olympic snowplow event. You won’t impress anyone on the slopes with your cool snowplow stance. It’s nothing to be embarrassed of, though. If people see you skiing that way, they’ll know you’re learning.

对我来说,故事模板有点像学习扫雪机。用它来写你的第一个故事的描述。大声说出来开始你的故事对话。但是,如果您发现它并不总是有效,请不要太担心。就像滑雪者的扫雪技术一样,它不是困难地形的最佳选择。

For me, the story template works a bit like learning the snowplow. Use it to write the descriptions of your first stories. Say it aloud to start your story conversations. But don’t get too concerned if you find that it doesn’t always work. Just like the snowplow technique for skiers, it’s not the best choice for difficult terrain.

我最喜欢的模板:如果我在便利贴或卡片上写故事,它们不会放在更大的故事地图中,我先给他们一个简短的标题,然后在标题下面写下:

My favorite template: if I’m writing stories on sticky notes or cards, and they won’t be sitting inside a bigger story map, I’ll first give them a short, simple title, and then under it I’ll write:

谁:

什么:

为什么:

Who:

What:

Why:

而且我会在每行之间给出几行,因为我想具体说出所有不同的人,说一下是什么,并记下不同的原因。当我们开始谈论这些故事时,我想在卡片上留出空间来添加额外的信息。当人们在卡片中间写标题时,这实际上是我的一个小毛病,因为当我们开始谈话时,我没有任何空间做笔记。但我就是那样挑剔。

And I’ll give a couple of lines in between each, because I’ll want to specifically name all the different whos, say a little about the what, and make notes about the different reasons why. I’ll want to leave room on the card to add extra information when we start talking about the stories. It’s actually a pet peeve of mine when people write the title in the middle of the card, because it doesn’t leave me any room to make notes when we start talking. But I’m nitpicky that way.

真正谈论什么的清单

A Checklist of What to Really Talk About

▢ 真正谈论谁
▢ Really talk about who

请不要只谈论“用户”。请明确点。谈谈你指的是哪个用户。对于 Gary,他可以谈论乐队经理或音乐迷。

谈论不同类型的用户。对于许多软件,尤其是消费类软件,使用相同功能的用户类型多种多样。从不同用户的角度谈论功能。

谈论客户。对于消费品,客户(或选择者)可能与用户是同一个人。但对于企业产品,我们需要讨论做出购买决定的人、他们的整个组织以及他们如何受益。

谈谈其他利益相关者。谈论赞助软件购买的人。谈论可能与用户合作的其他人。

很少只有一个用户很重要。

Please don’t just talk about “the user.” Be specific. Talk about which user you mean. For Gary, he could talk about the band manager or the music fan.

Talk about different types of users. For many pieces of software, especially consumer software, there are very diverse types of users using the same functionality. Talk about the functionality from different users’ perspectives.

Talk about the customers. For consumer products, the customer (or chooser) may be the same person as the user. But for enterprise products, we’ll need to talk about the people who make buying decisions, their organization as a whole, and how they benefit.

Talk about other stakeholders. Talk about the people sponsoring the software’s purchase. Talk about others who might collaborate with users.

There’s rarely just one user who matters.

▢ 真正谈论什么
▢ Really talk about what
我喜欢我的从用户任务开始的故事——人们想用我的软件做的事情。但是,在用户界面下方授权您的信用卡进行购买或在保险网站上验证您身份的服务呢?您的用户没有刻意选择让他们的信用卡通过:[授权]或验证他们的凭据。可以谈论服务和调用它们的不同系统。可以讨论特定的 UI 组件以及屏幕的行为方式。只是不要忘记谁在乎,为什么在乎。
I like my stories to start with user tasks—the things people want to do with my software. But what about services like the kind way beneath the user interface that authorizes your credit card for a purchase, or authenticates you on an insurance website? Your users didn’t make a deliberate choice to get their credit cards pass:[authorized] or have their credentials verified. It’s OK to talk about the services and the different systems that call them. It’s OK to talk about specific UI components and how the screen behaves. Just don’t lose sight of who cares, and why.
▢ 真的说说为什么
▢ Really talk about why

谈谈为什么特定用户关心。并深入挖掘“为什么”,因为通常有几个,而且它们是分层的。您可以长时间“用为什么坚持戳它”,以真正了解背后的原因。

谈谈为什么其他用户关心。谈谈为什么用户的公司关心。谈谈为什么业务利益相关者关心。为什么里面隐藏着很多伟大的东西。

Talk about why the specific user cares. And dig deeply into the “whys,” because there are often a few, and they’re layered. You can keep “poking it with the why stick” for a long time to really get at the underlying reasons why.

Talk about why other users care. Talk about why the user’s company cares. Talk about why business stakeholders care. There are lots of great things hidden inside why.

▢ 谈论软件之外发生的事情
▢ Talk about what’s going on outside the software
谈论使用您产品的人在使用产品时的位置。谈论他们何时使用该产品以及使用频率。谈论他们这样做时还有谁在那里。所有这些都提供了关于什么是好的解决方案的线索。
Talk about where people using your product are when they use it. Talk about when they’d use the product, and how often. Talk about who else is there when they do. All those things give clues about what a good solution might be.
▢ 谈谈出了什么问题
▢ Talk about what goes wrong
当出现问题时会发生什么?当系统宕机时会发生什么?用户还能如何做到这一点?他们今天如何满足他们的需求?
What happens when things go wrong? What happens when the system is down? How else could users accomplish this? How do they meet their needs today?
▢ 谈论问题和假设
▢ Talk about questions and assumptions

如果您谈论所有这些事情,您可能偶然发现了一些您不知道的事情。确定您的问题并讨论在构建软件之前获得答案的重要性。决定由谁来跑腿来回答这些问题,并将它们带回您的下一次对话。你会发现需要大量的对话来思考一些故事。

花时间质疑你的假设。你真的了解你的用户吗?这真的是他们想要的吗?他们真的有这些问题吗?他们真的会使用这个解决方案吗?

质疑您的技术假设。我们依赖哪些底层系统?他们真的像我们想的那样工作吗?是否存在我们需要考虑的技术风险?

所有这些问题和假设可能需要经过深思熟虑才能解决或学习。制定一个计划来做到这一点。

If you talk about all those things, you’ve likely stumbled across something you don’t know. Identify your questions and discuss how important they are to get answered before you build software. Decide who’ll do the legwork to get those questions answered, and bring them back to your next conversation. You’ll find it takes lots of conversations to think through some stories.

Take time to question your assumptions. Do you really understand your users? Is this really what they want? Do they really have these problems? Will they really use this solution?

Question your technical assumptions. What underlying systems do we rely on? Do they really work the way we think? Are there technical risks we need to consider?

All these questions and assumptions may require deliberate work to resolve or learn. Make a plan to do just that.

▢ 讨论更好的解决方案
▢ Talk about better solutions

当故事对话中的那些人放弃一些关于解决方案应该是什么的原始假设时,真正的大胜利就来了,回到他们试图解决的问题,然后一起得出一个更有效、更经济的解决方案。

没有标题的图片

The really big win comes when those in a story conversation discard some original assumptions about what the solution should be, go back to the problem they’re trying to solve, and then together arrive at a solution that’s more effective and more economical to build.

▢ 谈谈如何
▢ Talk about how

坐在故事对话中时,我经常听到有人焦急地说:“我们应该谈论什么,而不是如何!” 他们的意思是我们应该讨论用户需要做什么,而不是应该如何编写代码。当我们谈论“什么”而不谈论“为什么”时,我也感到同样的焦虑。但事实是,我们正试图在一个好的故事对话中针对所有这三个方面进行优化。出问题的是任何一方都认为特定的解决方案或其实施方式是“要求”。如果不明确谈论如何(如果您是开发人员,我知道您正在考虑),就很难考虑解决方案的成本。因为,如果解决方案太昂贵,那么它可能不是一个好的选择。

在谈话中尊重他人的专业知识。不要告诉训练有素的技术人员如何做她的工作。不要告诉非常熟悉用户及其工作的人他不理解的地方。提出问题,真诚地尝试相互学习。

When sitting in a story conversation, I often hear someone anxiously say, “We should be talking about the what, not the how!” By that they mean we should be talking about what users need to do, not how the code should be written. And I feel the same anxiousness when we talk about the “what” without talking about the “why.” But the truth is, we’re trying to optimize for all three in a good story conversation. What goes wrong is when either party assumes that a particular solution or the way it’s implemented is a “requirement.” Without explicitly talking about how (and if you’re a developer, I know you’re thinking about it), it’s difficult to think about the cost of the solution. Because, if a solution is too expensive, then it may not be a good option.

Be respectful of the expertise of others in the conversation. Don’t tell a highly trained technical person how to do her work. Don’t tell someone intimately familiar with users and their work that he doesn’t understand. Ask questions, and genuinely try to learn from each other.

▢ 谈谈多久
▢ Talk about how long

最终,我们需要做出一些决定来继续构建或不构建某些东西。在没有价格标签的情况下很难做出这种购买决定。

对于软件,这通常意味着编写代码需要多长时间。在早期的对话中,这可能会被表达为“很长一段时间”或“几天”。更好的是将它与已经构建的东西进行比较——“与我们上个月构建的评论功能大致相同。” 随着我们越来越接近构建某些东西,并且我们进行了更多的对话并做出了更多的决定,我们将能够更加精确。但我们始终知道我们在这里谈论的是估计,而不是承诺。

Ultimately, we need to make some decisions to go forward with building something or not. And it’s tough to make this sort of buying decision without a price tag.

For software, that usually means how long it’ll take to write the code. In early conversations, that might be expressed as “a really long time” or “a few days.” Even better is comparing it to something already built—“about the same as that feature for commenting we built last month.” As we get closer to building something, and we’ve had more conversations and made more decisions, we’ll be able to be a bit more precise. But we always know we’re talking about estimates here, not commitments.

创建度假照片

Create Vacation Photos

因为有很多话要谈,而且你不想忘记,所以确保您正在记录特定的事情,以帮助您记住您所做的决定,或者您需要研究的问题和假设。不要忘记将您的想法外化,以便讨论中的其他人可以看到记录的内容。

Because there’s a lot to talk about, and you won’t want to forget it, make sure you’re recording specific things that help you remember the decisions you made, or the questions and assumptions you’ll need to look into. Don’t forget to externalize your thinking so that others in the discussion see what’s recorded.

如果你写下来了,你可以拿起来以后参考。如果它贴在墙上,您只需指向它即可。而且,如果你们作为一个团队一起交谈,您会发现不必如此频繁地重复所有内容,因为人们会记住——尤其是如果您用简单的图画和文件……那些度假照片来固定你们的谈话。

If you write it down, you can pick it up and refer to it later. If it’s posted on the wall, you can just point at it. And, if you’re talking together as a team, you’ll find you won’t have to repeat everything so often, because people will remember—especially if you anchored your conversations with simple drawings and documents…those vacation photos.

没有标题的图片

这个小组正在进行故事讨论。在他们交谈时,他们将自己的想法形象化,并对他们的决定做笔记。

This small group is having a story discussion. As they talk, they visualize their ideas and make notes about what they decide.

我最喜欢的方法是做他们正在做的事情。我们谈话时,我会在活动挂图纸或白板上记录下来。我喜欢直接在黑板上记下谁在对话中,然后在完成后给黑板拍照。我将使用 wiki 或其他工具共享照片。我知道我可以在以后需要时提取细节或更正式地写下它们。如果我不记得确切说了什么,谈话中的其中一个人可能会记得。幸好我把他们的名字写下来了。

My favorite approach is to do exactly what they’re doing. I record on flipchart paper or a whiteboard as we talk. I like making a note of who was in the conversation directly on the board, and then photographing the board when I’m done. I’ll share the photo using a wiki or other tool. I know I can extract details or write them up more formally when I need them later. If I can’t remember exactly what was said, one of those people in the conversation might. It’s a good thing I wrote their names down.

有很多事情要担心

It’s a Lot to Worry About

想想你可以在故事中谈论多少内容是令人生畏的。在这一点上,您可能想回到过去的美好时光,那时您需要做的就是担心理解“需求”。回到真正解决问题不是您的工作的时候。回到你只需要构建你被告知的东西的时候,确保它是正确构建的东西是别人的问题。但我相信你和大多数人都非常喜欢解决问题。所以现在是你的机会。

It’s daunting to think about how much there is you could be talking about in stories. At this point, you may want to go back to the good old days when all you needed to do was worry about understanding the “requirements.” Back when it wasn’t your job to really solve problems. Back when you just needed to build what you were told to, and it was someone else’s problem to make sure it was the right thing to build. But I believe that you, and most people out there, really like solving problems. So now’s your chance.

您可能已经想到,要谈论所有这些事情,就会有很多信息需要跟踪。所有这些东西都放不下便签纸或索引卡。你是对的。它不会。那么让我们接下来谈谈这张卡上真正发生了什么,什么没有发生。

It may have occurred to you that with all these things to talk about, there will be a lot of information to keep track of. And all that stuff isn’t going to fit on a sticky note or an index card. You’re right. It won’t. So let’s talk next about what really does go on that card, and what doesn’t.




[ 10 ]这张照片由 Ruth Hartnup 拍摄,可在 Flickr 上找到,并根据 Creative Commons Attribution License 获得许可。

[10] This photo was taken by Ruth Hartnup, found on Flickr, and licensed under the Creative Commons Attribution License.

Chapter 8. 事情并非一帆风顺

Chapter 8. It’s Not All on the Card

是的,主要的想法是卡片上的短篇小说标题将帮助我们计划和促进可以构建软件的人和理解需要用它解决的问题的人之间的大量对话。但是,可悲的是,将完成的软件产品推出市场需要的不仅仅是几个人。

Yes, the big idea was that short story titles on cards would help us plan and facilitate lots of conversations between the people who could build software and the people who understood the problems that needed to be solved with it. But, sadly, it takes more than a couple of people to get a finished piece of software out the door.

在一个典型的团队中,您会发现项目经理、产品经理、业务分析师、测试人员、用户体验设计师、技术作家和我可能忘记的其他一些角色。他们都在看同样的卡片,但他们的谈话会有所不同,因为他们都有不同的关注点要照顾。

On a typical team you’ll find project managers, product managers, business analysts, testers, user experience designers, technical writers, and some other roles I’m probably forgetting. They’re all looking at the same cards, but the conversations they have are going to be different because they’ve all got different concerns to look after.

不同的人,不同的对话

Different People, Different Conversations

没有标题的图片

如果我是产品经理或产品负责人,并且我对这款产品的成功负有责任,那么我必须对我的目标市场有更多的了解。我需要假设有多少人会购买或使用该产品,或者它将如何影响我公司的盈利能力。我想谈谈那些事情。

If I’m a product manager or product owner, and I’m responsible for the success of this product, then I have to know a little more about my target market. I need to form some hypothesis about how many people will buy or use this product, or how it’s going to affect the profitability of my company. I’ll want to talk about those things.

如果我是一名业务分析师,我可能会深入研究很多细节,所以我需要了解用户界面中正在发生的事情,以及用户界面背后的系统中的业务规则。

If I’m a business analyst, I might be diving into a lot of details, so I need to understand what’s going on in the user interface, and the business rules in the system that are behind the user interface.

如果我是一名测试人员,我需要考虑软件可能在哪些方面出现故障。我需要进行一些对话来帮助我制定一个好的测试计划。

If I’m a tester, I need to think about where the software is likely to fail. I need to have some conversations to help me put together a good test plan.

如果我是一名 UI 设计师,我不想被告知 UI 是什么样子,就像开发人员不想被告知代码应该如何编写一样。我想知道谁在使用它,为什么以及他们在做什么,这样我就可以设计一个有用且可用的用户界面。

If I’m a UI designer, I don’t want to be told what the UI looks like any more than a developer wants to be told the way the code should be written. I’ll want to know who’s using it, and why and what they’re doing, so I can design a useful and usable user interface.

最后,如果我是负责协调这群人的项目经理,我将不得不注意他们在讨论所有这些细节时做出决定。当它开始时,我需要注意依赖关系、时间表和开发状态。

Finally, if I’m a project manager responsible for coordinating this group of people, I’ll have to pay attention when all of them are talking to make decisions about all these details. I’ll need to pay attention to dependencies, schedules, and the status of development when it gets started.

这是很多对话。其中一些必须先于其他发生。而且其中许多发生不止一次。因此,为了使其准确,我们可能必须在 3个C中再添加十几个C。但令人高兴的是,如果你们真的在一路上进行对话并建立共同的理解,你就会避免很多误解和路线更正。

That’s a lot of conversations. And some of them have to happen before others. And many of them happen more than once. So, to make it accurate, we’d probably have to add another dozen C s to the 3 C s. But happily, if you’re really having conversations and building shared understanding along the way, you’ll avoid lots of misunderstandings and course corrections.

每个故事都有与不同人进行的许多不同类型的对话。

There are many different kinds of conversations with different people for every story.

我们需要一张更大的卡片

We’re Gonna Need a Bigger Card

当你说出那个标题中的词时,我希望你会想起老电影《大白鲨》,在第一次近距离亲眼看到这条巨大的鲨鱼后,警察局长布罗迪对昆特说:“你需要一艘更大的船。”

When you say the words in that heading, I hope you’re thinking of the old movie Jaws when, after seeing the huge shark up close and personal for the first time, Police Chief Brody says to Quint, “You’re gonna need a bigger boat.”

没有标题的图片

你看,最初的想法也是,我可以拿起一张卡片,在正面写上标题,然后当我们交谈时,我可以把它翻到背面,写下我们同意的所有事情的细节上来了。我可以画出用户界面的草图,并在卡片上写下很多其他信息。在某些项目上,它确实可以这样工作。可以的话很酷,这通常是小团队紧密合作并拥有大量隐性知识的副作用。这些是不需要写太多就可以记住的团队。

You see, the original idea was also that I could pick up a card and write the title on the front, and then as we had conversations, I could flip it over on the back and write the details of all the things we agreed to that came up. I could sketch the user interface and write a lot of other information on the card. On some projects, it can really work this way. It’s cool when it can, and it’s usually a side effect of small teams working closely together with a lot of tacit knowledge. Those are the teams that don’t have to write much to remember.

但我认为即使是 Kent 和那些完善故事概念的人实际上也没有想到所有这些不同的人之间的所有这些对话都可以包含在一张卡片上,事实上,他们通常不会。

But I don’t think even Kent and the folks who perfected the concept of stories actually thought that all these conversations between all these different people could be contained on just a single card, and in fact, they usually aren’t.

对我有用的比喻是图书馆卡片目录中的一张卡片,对于年龄足够大的人来说,图书馆实际上卡片目录。写在卡片上的故事有点像那些。

The metaphor that works for me is a card in a library card catalog, for people who are old enough to remember when libraries actually had card catalogs. Stories written on cards work a bit like those.

没有标题的图片

如果我从卡片目录中挑选一张卡片,它会提供足够的信息让我识别这本书。它可能有标题、作者姓名、描述、书的页数、书的类别(例如“非小说类”)和代码(还记得杜威先生的小数点吗?)到我可以实际找到的位置图书馆里的那本书的副本。该卡只是一个易于查找和整理的标记。没有人会将卡片与一本书混淆。卡片目录很方便,因为它比成千上万本书占用的空间要少得多。我可以用不同的方式组织卡片——例如,按作者或按主题。

If I pick up a card from a card catalog, it’s going to have just enough information for me to identify the book. It likely has a title, the author name, a description, the page count of the book, the category of the book—like “nonfiction”—and a code (remember Mr. Dewey’s decimals?) to a location where I can actually find a copy of the book in the library. The card’s just a token that’s easy to find and organize. No one confuses the cards with a book. The card catalog is handy because it takes a lot less space than thousands of books would. And I can organize cards in different ways—by author, for example, or by subject.

您的故事将以同样的方式运作;也就是说,您可以将它们写在卡片上,将它们保存在电子表格的列表中,将它们输入到您最喜欢的跟踪工具中,或者将它们输入到您公司让您使用的跟踪工具中——您知道,每个人都在抱怨这个工具。在图书馆里,您知道某处有一本书,如果您在卡片目录中找到了正确的卡片,就很容易找到它。同样,对于一个故事,您知道某处的信息量越来越多。它随着每次对话而成长和发展。而且,希望无论您的公司选择如何跟踪这些信息,它也很容易找到。

Your stories will work the same way; that is, you may write them on cards, keep them in a list in a spreadsheet, enter them into your favorite tracking tool, or enter them in the tracking tool your company makes you use—you know, the one everyone grumbles about. In a library, you know there’s a book out there somewhere, and if you have identified the right card filed away in the card catalog, it’s easy to find it. Similarly, with a story, you know there’s a growing amount of information out there somewhere. It grows and evolves with each conversation. And, hopefully, however your company chooses to keep track of the information, it’s easy to find, too.

如果你想去真正的老派,请保留细节所有这些讨论都贴在墙上的大张挂图纸上,这样你就可以随时谈论它们。但请记住:当你完成工作时,你会想把它们拿下来,否则你会用完墙上的空间。你会想要给它们拍照,并将这些照片保存在某个地方以供子孙后代使用。

If you want to go really old school, keep the details of all those discussions taped onto big sheets of flipchart paper on the wall so you can keep talking about them whenever you want. But remember: you’ll want to take them down when you’ve completed the work or else you’ll run out of wall space. And you’ll want to photograph them and keep those photos somewhere for posterity.

散热器和冰箱

Radiators and Ice Boxes

在他的《敏捷软件开发:合作博弈》(Addison-Wesley Professional)一书中,Alistair Cockburn 创造了术语信息辐射器来描述墙上有多大的可见信息将有用的东西辐射到房间里。路过的人看着它并与之互动。当信息活跃且有用时,许多对话最终会出现在墙上,人们可以指向并添加到那里积累的信息中。

In his book Agile Software Development: The Cooperative Game (Addison-Wesley Professional), Alistair Cockburn coined the term information radiator to describe how big, visible information on the wall radiates useful stuff into the room. People walking by look at it and engage with it. When the information is alive and useful, lots of conversations end up at the wall, where people can point to and add to the information accumulating there.

当我走进墙壁干净,甚至覆盖着令人愉悦的艺术品——或者最糟糕的是,励志海报——的环境时,我会感到难过。这些有用的墙壁每天都可能发生如此多的伟大合作。如果墙上的东西是一个信息辐射器,有些人将人们使用的工具称为信息冰箱——因为这是保存信息的地方——并且可能会被一层薄薄的冰覆盖,就像你的后背的东西一样冰箱。(我总是对我在那里的发现感到震惊。)

When I walk into environments where the walls are clear, or even covered with pleasant artwork—or worst of all, motivational posters—it makes me sad. There’s so much great collaboration that could be happening every day with those useful walls. If what’s on the wall is an information radiator, some refer to the tools people use as an information icebox—because that’s where information goes to be preserved—and potentially be crusted over with that thin layer of ice like that stuff in the back of your freezer. (I’m always shocked by what I find back there.)

这就是 Atlassian 对我来说真正了不起的地方。他们使信息保持活力和有用,无论是在他们使用的工具中还是在他们使用的工具之外。

That’s what’s really remarkable to me about Atlassian. They keep information alive and useful, both in and out of the tools they use.

那不是那个工具的用途

That’s Not What That Tool Is For

伐木工人在森林里遇到了一个人。这个人正在努力工作,试图通过用锤子敲打来砍倒一棵树。伐木工人拦住男人说:“嘿,你用错工具了!试试这个……”然后递给那个人一把锯。男人向他道谢,伐木工人继续赶路,他很高兴知道自己帮了忙。然后这个人开始用锯子敲树,就像他用锤子一样。

A lumberjack comes across a man in the forest. The man is working hard trying to chop down a tree by hitting it with a hammer. The lumberjack stops the man and says, “Hey, you’re using the wrong tool! Try this…” and hands the man a saw. The man thanks him, and the lumberjack continues on his way, happily knowing that he’s helped. The man then begins striking the tree with the saw the same way he was with the hammer.

这个笑话提醒我,我们可以用错工具,也可以用工具。

This joke reminds me that we can use the wrong tool for the job, and we can also use the tool wrong.

当我告诉人们像 Atlassian 这样的公司如何使用工具时,他们通常会感到惊讶。他们常常感到惊讶,因为他们一直在尝试使用工具来替代白板和便利贴。而且,可以预见的是,他们一直在努力解决这个问题。可能是他们为错误的工作使用了错误的工具,或者错误地使用了正确的工具。要弄清楚可能出了什么问题,最好先查看作业,而不是工具。

When I tell people how companies like Atlassian use tools, they’re usually surprised. They’re often surprised because they’ve been trying to use tools as a replacement for whiteboards and sticky notes. And, predictably, they’ve been struggling with that. It may be that they’re using the wrong tool for the wrong job, or using the right tool wrong. To figure out what might be going wrong, it’s best to look at the job first, and not the tool.

建立共识

Building Shared Understanding

当我们共同讲述故事并就要构建的解决方案做出决策时,我们的首要目标是建立共同的理解。这就是外化和组织您的想法至关重要的地方。没有什么比在白板前用便利贴进行面对面的工作更好的了。但是,如果您必须与远程工作的其他人一起完成这项任务,那就很难了。让您看到彼此面孔的视频会议工具并没有太大帮助,因为您需要看到的不是他们的面孔,而是您将要放在墙上或桌面上的想法。

When we’re working together to tell stories and make decisions about solutions to build, our first goal is to build shared understanding. This is where externalizing and organizing your thoughts is critical. And nothing beats face-to-face work in front of a whiteboard, armed with sticky notes. But, if you’ve got to accomplish this task with others working remotely, this is tough. Video conference tools that let you see one another’s faces don’t help much, since it’s not their faces you need to see—it’s the ideas you’ll be placing on the wall or tabletop.

在视频会议期间使用文件摄像机或网络摄像机,让远程人员可以看到墙上正在创建的内容。

Use a document camera or web camera during a video conference to let remote people see what’s being created on the wall.

我曾与在视频会议两端都有摄像机的团队合作过,通话的重点是墙上不断增长的模型,而不是团队成员的脸。

I’ve worked with teams that have video cameras at both ends of a video conference, and the call focuses on the growing models on the wall, not the team members’ faces.

如果你使用一种工具来可视化,那么理想的情况是对话双方的人都可以添加和移动东西,就像他们在白板上一起工作一样。这是来自名为 Cardboard 的工具的屏幕。

If you use a tool to visualize, it’s ideal if people on both sides of the conversation can add and move things around, just like they could if they were working together at a whiteboard. This is a screen from a tool called Cardboard.

没有标题的图片

使用 Cardboard 的人正在创建地图,而 Cardboard 的创建者之一 David Hussman 在墙上绘制地图。从其他位置共享同一张地图的其他人会看到它实时汇集在一起​​。他们可以添加、删除和更改卡片,每个人都可以看到其他人在做什么。您几乎可以“退后一步”并立即查看整面墙,这很方便,因为计算机屏幕只是您在墙上工作时可以看到的内容的一个小入口。

The person using Cardboard is creating a map at the same time as David Hussman, one of Cardboard’s creators, maps on a wall. Others who are sharing the same map from other locations see it come together in real time. They can add, remove, and change cards, and everyone can see what everyone else is doing. You can virtually “step back” and look at the entire wall at once, which is handy because computer screens are just a tiny portal on what you could see if you were working at a wall.

远程协作时,使用允许每个人同时查看、添加和组织模型的工具。

When collaborating remotely, use tools that allow everyone to see, add to, and organize the model concurrently.

令人高兴的是,我看到越来越多的工具进入市场,它们理解并支持一起工作以建立共同的理解。这是一件好事。

Happily, I’m seeing a lot more tools enter the market that understand and support working together to build shared understanding. This is a good thing.

记住

Remembering

当我们一起努力达成一致时,我们应该保留我们创建的任何模型或示例的副本以用作度假照片——以帮助我们记住我们讨论过的所有细节。像 Atlassian 的 Confluence 这样的工具提供了丰富的 wiki,不仅可以存储文字,还可以存储图片和视频。一起工作后拍摄并保存照片和视频是最快的记录方式之一。

When we’ve worked hard together to get on the same page, we should be keeping copies of whatever models or examples we’ve created to use as vacation photos—to help us remember all the details we’ve discussed. Tools like Atlassian’s Confluence offer a rich wiki for storing not just words, but also pictures and video. Taking and keeping pictures and videos after working together is one of fastest ways to document.

没有标题的图片

Atlassian 的这些人正在这样做。他们在墙上工作后拍了一张照片,并将其上传到他们的 wiki 以妥善保管。

These folks at Atlassian are doing just that. They’ve snapped a picture after working at a wall, and uploaded it to their wiki for safekeeping.

使用工具发布图片、视频和文本,以帮助您保留和记住您的对话。

Use tools to post pictures, videos, and text to help you retain and remember your conversations.

我个人喜欢保持低保真并在墙上保留信息,但如果我担心清洁工在晚上将其取下,我会拍照并保存以防万一。如果我要与不能在房间里的人分享信息,即使是虚拟的,我也会拍摄一段短视频,介绍墙上的模型,并将其张贴在其他人可以看到的地方。

I personally like staying lo-fi and keeping information on the wall, but if I worry at all about a cleaning person taking it down at night, I’ll photograph and keep it just in case. If I’m sharing information with people who couldn’t be in the room, even virtually, I’ll shoot a short video stepping through the model on the wall and post that where others can see it.

追踪

Tracking

工具最擅长的事情之一就是完成我们计划要做的所有工作,并让我们跟踪其进度。工具可以很好地跟踪对我们来说很乏味的数字——比如我们确切的开始时间、完成时间以及还有多少事情要做。当我们定期跟踪我们正在做的事情时,更好的工具将为我们产生有用的见解。

One of the things that tools most excel at is taking all the work we’ve planned on doing, and letting us track its progress. Tools are great at keeping track of the numbers that are tedious for us—things like exactly when we started, when we finished, and how much we’ve got left to do. The better tools will generate useful insights for us as we routinely track what we’re doing.

没有标题的图片

这是Atlassian的JIRA产品生成的累积流程图。这是一张图表,显示我们正在做的工作及其随时间的状态。这是一张我不愿意手工制作的图表。

This is a cumulative flow diagram generated by Atlassian’s JIRA product. It’s a chart that shows the work we’re doing and its state over time. And it’s a chart I would hate to produce by hand.

对于单一的、并置的团队和小型项目,墙就可以了。但是,如果您有更大的团队在不同的物理位置工作,并且项目运行时间更长,请使用工具来跟踪所有细节。

For single, collocated teams and small projects, the wall will do just fine. But, if you’ve got larger teams working from different physical locations, and longer-running projects, use a tool to keep track of all the details.

使用工具来排序、跟踪和分析进度。

Use tools to sequence, track, and analyze progress.

诀窍是为正确的工作使用正确的工具。不要尝试使用非常棒的跟踪工具来建立共同的理解。不要费力地在白板上进行复杂的分析。

The trick is using the right tool for the right job. Don’t try to use a really great tracking tool to build shared understanding. And don’t struggle to do complex analysis on a whiteboard.

保持事情简单快速,尽可能多地在索引卡和白板上工作一直是敏捷的理想。我向你保证,如果你能保持小而快,避免使用不必要的工具,你会更快乐。但请记住:这些工具只是达到目的的一种手段。接下来,我们需要谈谈卡片之后会发生什么。

It’s been an Agile ideal to keep things simple and fast, to stay working on index cards and whiteboards as much as possible. And I promise you if you can stay small and fast and avoid unnecessary tools, you’ll be happier. But remember: those tools are just a means to an end. Next, we’ll need to talk about what happens after the card.

第 9 章卡片只是开始

Chapter 9. The Card Is Just the Beginning

三个C只是开始。

The three C s are just the beginning.

我知道我之前说过我没有义务引用敏捷宣言,但无论如何我都会引用——好吧,至少引用其中的一小部分。宣言中的价值陈述之一是“工作软件胜过综合文档”。我可以将其改写为“综合对话中的工作软件”,意思是一样的。所有这些对话——以及帮助我​​们回忆它们的文档——只是达到目的的一种手段。最终我们需要建造一些东西。

I know I said earlier that I don’t feel obligated to quote the Agile Manifesto, but I’m going to anyway—well, at least a small part of it. One of the value statements in the manifesto reads “Working software over comprehensive documentation.” I could rephrase that as “working software over comprehensive conversation,” and the meaning would be the same. All those conversations—and the documentation that helps us recall them—are just a means to an end. Eventually we’ll need to build something.

如果我们完成循环,模型如下所示:

If we finish the cycle, the model looks like this:

没有标题的图片

在我们对我们将要构建的内容达成共识并达成共识之后,总会有一些问题潜入这里。留意他们。

There are some gotchas that always manage to sneak in here after we’ve got shared understanding and agreement on what we’ll build. Keep an eye out for them.

在脑海中构建清晰的画面

Construct with a Clear Picture in Your Head

在进行对话并写下有助于我们记住这些对话的细节并写下确认之后——也就是说,我们同意我们将检查以确认我们已经完成的事情——我们终于准备好做一些事情了:

After having conversations, and writing down details that’ll help us remember those conversations, and writing down confirmation—that is, our agreement about the things we’ll check to confirm we’re done—we’re finally ready to make something:

  • 软件开发人员可以开始构建软件。
  • Software developers can get started building the software.
  • 测试人员可以创建测试计划并进行测试。
  • Testers can create test plans and test.
  • UI 设计师可以创建详细的 UI 设计和数字资产,如果他们还没有这样做的话,作为达成共识的一部分。
  • UI designers can create detailed UI design and digital assets, if they haven’t already done so as part of arriving at a shared understanding.
  • 技术作家可以编写或更新帮助文件或其他文档。
  • Technical writers can write or update help files or other documents.

这里最重要的是,所有这些人的脑袋里都装着同一张图:他们 一起谈话时构建的图。

The most important thing here is that all these people are armed with the same picture in their heads: the picture they built while talking together.

我要在这里暂停一下。

I’m going to pause here for effect.

现在,我要慢慢说下一部分,所以你应该慢慢读。

Now, I’m going to say this next part slowly, so you should read it slowly.

将故事的所有细节交给其他人来构建是行不通的。不要那样做。

Handing off all the details about the story to someone else to build doesn’t work. Don’t do that.

如果你和一群人一起工作来理解应该构建什么,并且如果你已经记录了构建它需要知道的所有重要事情,那么你可能很想把它交给其他人。毕竟,当您查看这些信息时,它对您来说一清二楚。但不要自欺欺人。你很清楚,因为你真正聪明的大脑正在填写所有没有写下来的细节。你的大脑非常擅长它,以至于你很难发现可能遗漏了什么。请记住,这些细节是您的度假照片,而不是他们的

If you and a group of people have worked together to understand what should be built, and if you’ve documented all the important things someone needs to know to build it, you may be very tempted here to hand it off to someone else. After all, when you look at the information, it’s crystal clear to you. But don’t fool yourself. It’s clear to you because your really smart brain is filling in all the details that aren’t written down. Your brain is so good at it that it’s hard for you to detect what could be missing. Remember, those details are your vacation photos, not theirs.

建立讲故事的口头传统

Build an Oral Tradition of Storytelling

分享故事相当简单。真正理解故事的人,以及收集到的有助于讲述故事的信息,只需要花一点时间将故事复述给下一个需要学习的人。现在,这应该比你们一起做出艰难决定的早期对话要快得多,因为希望你们不需要重新做出决定。使用所写的内容来帮助讲述故事。说话并指着图片。让您的听众提出问题并对图片进行修改以帮助她记住。帮助她将与故事相关的信息变成她自己的度假照片。

Sharing stories is reasonably simple. Someone who does understand the story, and the information collected that helps tell the story, needs only spend a little time retelling the story to the next person who needs to learn. Now, this should go lots faster than early conversations where you worked together to make tough decisions, since hopefully you won’t need to remake them. Use what’s written to help tell the story. Talk and point to pictures. Let your listener ask questions and make changes to the pictures that help her remember. Help her turn the information associated with the story into her own vacation photos.

没有标题的图片

我经常在这里看到一个讨厌的反模式。有些人认为,既然团队中的任何人都可能会拿起故事并为之工作,那么团队中的每个人都应该参与到每一次对话中。也许你在这家公司工作。你会知道的,因为你会听到很多人抱怨会议太多了。顺便说一句,“会议”通常是我们用来指代无效协作的委婉说法。

There’s a nasty anti-pattern I often see here. Some think that since anyone in a team might pick up the story and do work on it, everyone on the team should be involved in every conversation. Perhaps you work at this company. You’ll know it because you’ll hear lots of people complaining that there are way too many meetings. By the way, “meeting” is often the euphemism we use for unproductive collaboration.

两到五人的小组最适合进行有效的讨论和决策。这是晚餐谈话的大小。您知道,如果您有一群朋友共进晚餐,那么在只有几个人的情况下很容易进行一次对话。但只要超过五个人,它就会成为真正的努力。

Effective discussion and decision making goes best with small groups of two to five. It’s dinner conversation sized. You know that if you have a group of friends sharing a meal, it’s easy to hold a single conversation when there are just a few of you. But any more than about five people is where it becomes a real effort.

让小组一起做决定,然后通过持续的对话与其他人分享结果。

Let small groups work together to make decisions, and then use continued conversations to share the results with everyone else.

检查你的工作结果

Inspect the Results of Your Work

如果你在团队中,你们将一起工作,并对你正在构建的内容和原因有共同的理解。当你们一起工作时,你们会一直进行对话,因为你们永远不会考虑所有事情。但是当软件完成后,你们会一起回来讨论它。

If you’re on the team, you’ll all work together armed with shared understanding about what you’re building, and why. As you work together, you’ll keep having conversations because you never think of everything. But when the software is done, you’ll all come back together and talk about it.

现在是祝贺自己工作出色的好时机。看到真正的进步真是太棒了。在传统的软件开发中,看到辛勤工作成果的机会要少得多,而且很少作为团队共享。在像 Scrum 这样的典型敏捷流程中,您将每隔几周在冲刺结束时进行一次产品评审。在最健康的团队中,团队成员经常聚在一起检查他们完成的工作。但你需要超越展示和讲述。祝贺自己之后,花点时间对自己所做工作的质量进行简短而认真的反思。

This is a good time to congratulate yourselves on a job well done. It’s pretty cool to see real progress. In traditional software development, the opportunities to see the results of your hard work can come a lot less frequently, and they’re rarely shared as a team. In a typical Agile process like Scrum, you’ll be sharing every couple of weeks at an end-of-sprint product review. In the healthiest of teams, team members get together frequently to inspect their work as it’s done. But you’ll need to go beyond show and tell. After congratulating yourselves, take time for a short but serious reflection on the quality of the work you did.

说到质量,我先从这三个方面开始讨论:

When talking about quality, I start with discussions of these three aspects:

用户体验质量
User experience quality
从目标用户的角度审视作品。使用起来简单吗?使用起来有趣吗?好看吗?它与您的品牌和其他功能一致吗?
Review the work from the perspective of its target user. Is it straightforward to use? Is it fun to use? Does it look good? Is it consistent with your brand and other functionality?
功能品质
Functional quality
该软件是否按您同意的方式运行,没有错误或错误?希望测试人员和其他团队成员花时间进行测试,并且您已经修复了所有错误。但是优秀的测试人员通常会告诉您,您的产品中可能潜伏着更多错误,这些错误可能会在以后出现。或者希望他们可以说它感觉坚如磐石。
Does the software do what you agreed it would without bugs or errors? Testers and other team members have hopefully spent time testing and you’ve fixed any bugs already. But good testers can often tell you that there are likely more bugs lurking in your product that may emerge later. Or hopefully they can say that it feels rock solid.
代码质量
Code quality
我们写的软件质量高吗?符合我们的标准吗?我们可能会拥有这些东西一段时间,所以最好知道我们是否认为它易于扩展和维护,或者我们是否只是添加了一堆我们需要稍后解决的技术债务。
Is the software we wrote high quality? Consistent with our standards? We may own this stuff for a while, so it’d be good to know if we think it’ll be easy to extend and maintain, or if we’ve just added a pile of technical debt we’ll need to address later.

我有一些坏消息要告诉你。你可能会发现你认为应该改变你所做的事情。

I have some bad news for you here. You’re likely to find things you believe should change about what you’ve done.

将两个问题分开会有助于每个人的理智。第一:我们是否建造了我们同意建造的东西?然后:如果这是我们同意建造的,既然我们看到了,我们是否应该做出一些改变?

It’ll help everyone’s sanity to separate out two concerns. First: did we build what we agreed to build? And then: if it’s what we agreed to build, now that we see it, should we make some changes?

每个人都会在一开始就一起努力工作,以弄清楚要构建什么来解决用户的问题并且构建起来是经济的。您将尽最大努力确定要检查的内容以确认它已完成。检查所有这些事情,如果你已经完成那么多,祝贺你自己。你得到的正是你同意你想要得到的。

Everyone will have worked hard together at the outset to figure out what to build that would solve users’ problems and be economical to build. You’ll have done your best to identify the things to check to confirm that it’s done. Check all those things, and congratulate yourselves if you’ve accomplished that much. You got exactly what you agreed you wanted to get.

现在,我脑海中浮现出一些滚石乐队的老歌歌词。如果你知道这首歌,请跟着哼唱:“你不能总是得到你想要的。但是,如果你尝试一下,你可能会发现,你得到了你需要的东西。” 具有讽刺意味的是,软件恰恰相反。

Now, here’s where some old Rolling Stones song lyrics play in my head. If you know the song, hum along: “You can’t always get what you want. But, if you try sometime, you just might find, you get what you need.” The irony with software is that it’s exactly the opposite.

你们将共同努力,就你们想要的达成一致。而且,如果您与一个有能力的团队一起工作,您会发现您可以非常擅长获得它。但是,只有在看到它之后,您才能更好地评估它是否是您需要的。这很糟糕。但不要责怪自己——事情就是这样。

You’ll work together to agree on what you want. And, if you’re working with a competent team, you’ll see that you can get pretty good at getting it. It’s only after seeing it, though, that you can better evaluate if it’s what you need. This sucks. But don’t blame yourselves—that’s just the way it works.

但是,您确实有办法修复它。它首先写一张卡片,上面写着你对软件进行哪些更改以修复它的想法。当然,如果您一开始就打算做对,这就很糟糕了。也许 Mick Jagger 终究是对的。也许你真正需要的是了解第一次就正确是一种冒险的策略——尤其是在软件领域。

You do, however, have a way of fixing it. And it starts by writing a card with your ideas about what to change in the software to fix it. This, of course, sucks if you’d planned on being right the first time. Maybe Mick Jagger was right after all. Maybe what you really needed was to learn that being right the first time is a risky strategy—especially in software.

这不适合你

It’s Not for You

对不起。我有更多的坏消息。

I’m sorry. I’ve got even more bad news.

实际上,最初编写卡片并开始整个循环的人很可能不是每天都会使用该软件的人。最初编写这张卡片的人,以及一起工作的整个团队,可能相信他们已经做到了——他们已经为目标用户所面临的挑战构建了完美的解决方案。

In reality, the person who originally wrote the card and who started this entire cycle is likely not the person who will use the software every day. The person who originally wrote the card, and the entire team who worked together, may believe they’ve nailed it—that they’ve built the perfect solution to the challenges their target users have.

不要自欺欺人。

Don’t fool yourself.

如果我们一起加入这个团队并且我们很聪明,我们会将软件带给用户并与他们一起测试。这也不是展示和讲述。我们将通过观察他们使用该软件来实现他们通常需要使用该软件来实现的真实目标来进行测试。

If we’re on this team together and we’re smart, we’ll take the software out to users and test it with them. This isn’t show and tell, either. We’ll test by watching them use the software to reach a real goal they’ll normally need to accomplish using the software.

当某人使用您帮助构建的软件时,您是否曾与她坐在一起?回想一下你第一次这样做。进展如何?当时我不在房间里和你在一起,但我敢打赌,事情并没有像你预期的那样进行。

Have you ever sat with someone as she uses software you’ve helped build? Think back to the first time you did. How did it go? I wasn’t in the room with you at the time, but I’m willing to bet that it didn’t go the way you expected.

如果您曾经在用户使用您的产品时坐在她旁边,您就会明白我的意思。如果您从未这样做过,那就去做吧。

If you’ve ever sat next to a user as she uses your product, you know what I mean. If you’ve never done this, then do it.

您需要对实际购买、采用和使用您的产品的人进行测试,这些人会以一定的频率定期使用您的产品。我经常等到我构建了一些软件——足够他们可以用它来完成他们以前无法完成的事情。无论您采用何种频率,都不要让超过几周的时间没有看到真正的用户与该软件进行交互。

You’ll need to test with the people who’ll actually buy, adopt, and use your product at some regular frequency. I often wait until I’ve built up a bit of software—enough that they could use it to accomplish something they couldn’t before. Whatever frequency you adopt, don’t let more than a couple weeks go by without seeing a genuine user interact with the software.

团队中的每个人都不需要与用户在一起。事实上,如果每个人都这样做,它会让用户感到厌烦。但是在那里建立同理心,你不会得到任何其他方式。看到人们努力使用您的产品是一种强大的动力,尤其是当您确信他们不需要时。如果您在场,请通过向他人讲述故事来与他人分享您的所见所闻。

Everyone on the team doesn’t need to be there with users. In fact, it’ll kind of creep the users out if everyone is. But being there builds empathy that you won’t get any other way. It’s a powerful motivator to see people struggling to use your product, especially when you were so confident they wouldn’t need to. If you were there, share what you saw with others by telling stories back to them.

与用户一起测试后,您将确定要解决的问题和改进软件的明显方法。对于其中的每一件事,您都应该写一张故事卡,其中包含您改进软件的想法。

After testing with users, you’ll identify problems to fix and obvious ways to improve the software. And for each one of those things, you should write a story card with your ideas for improving the software.

构建学习

Build to Learn

如果您一直相信使用故事可以阻止您的团队编写糟糕的软件,那么您至少对了一半。事实上,聪明人之间的所有对话都集中在理解问题上——以及我们正在构建的产品如何解决它——对制造更好的产品大有帮助。但我们需要承认,构建软件与在流水线上工作不同。您不只是像几分钟前构建的那样再构建一个小部件。我们创建软件支持的每个新故事都是新事物。

If you’d labored under the belief that using stories would stop your team from writing bad software, you were at least half right. In fact, all the conversations between smart people focused on understanding the problem—and how what we’re building solves it—go a long way toward making a much better product. But we need to acknowledge that building software isn’t the same as working on an assembly line. You’re not just building one more widget like the one you built a few minutes ago. Each new story we create software to support is something new.

敏捷开发社区中的一位杰出人物是我的前面提到的朋友,Alistair Cockburn,他曾经告诉我,“对于你写的每一个故事,你需要将三个故事放入积压的故事中。”

One of the luminaries in the Agile development community is my aforementioned friend, Alistair Cockburn, who once told me, “For every story you write, you need to put three into your backlog of stories.”

我问他为什么,他说:“你就是这样。”

I asked him why, and he said, “You just do.”

我问:“另外两个应该写什么?”

I asked, “What should I write on the other two?”

“你写什么并不重要。”

“It doesn’t matter what you write.”

“你是什么意思?” 我问:“我必须在上面写点东西

“What do you mean?” I asked, “I have to write something on them!”

阿利斯泰尔回答说:“好吧,如果你必须在上面写点什么,那就在第一张卡片上写下你想要的东西,然后在第二张卡片上写下‘修复第一张卡片’。” 然后在第三张卡片上,写下“修复第二张卡片”。如果你不为每个故事绕过这个循环 3 次,你就不是在学习。”

Alistair replied, “Well, if you have to write something on them, then write what you want on the first card, and on the second card write ‘Fix the first card.’ Then on the third card, write ‘Fix the second one.’ If you aren’t going around this cycle three times for each story, you’re not learning.”

在传统流程中,学习被称为范围蔓延不良需求在敏捷过程中,学习是目的。您需要计划从您构建的所有内容中学习。而且你需要计划在相当多的时间里犯错。

In a traditional process, learning gets referred to as scope creep or bad requirements. In an Agile process, learning is the purpose. You’ll need to plan on learning from everything you build. And you’ll need to plan on being wrong a fair bit of the time.

Eric 在第 3 章中使用的策略帮助他构建较小的解决方案并继续迭代它们直到它们可行。Eric 指望从每个版本中学习。

Eric’s strategy used in Chapter 3 helped him build smaller solutions and continue to iterate them until they were viable. Eric counted on learning from every release.

蒙娜丽莎策略_Mike 和 Aaron 在第 4 章中使用的方法帮助他们将每个故事分成更小、更薄、无法交付的部分,这样他们就可以更快地学习并明智地管理他们的交付预算以按时完成。

The Mona Lisa strategy used by Mike and Aaron in Chapter 4 helped them slice every story down into smaller, thinner, undeliverable bits so they could learn sooner and manage their delivery budget wisely to finish on time.

这些都是很好的学习策略。试试那些。发明你自己的。但请不要假设你总是对的。我保证你会失望的。

These are both great learning strategies. Try those. Invent your own. But please don’t assume you’re always right. I promise you’ll be disappointed.

它并不总是软件

It’s Not Always Software

2011 年,故事的作者肯特·贝克 (Kent Beck) 通过对敏捷宣言的修订开启了首批精益创业会议之一。如果我这样做了,那可能就是亵渎神明。但他是它的创造者之一,所以他应该知道。他修改了阅读有关工作软件的价值:

In 2011, Kent Beck—the creator of the story—opened one of the first Lean Startup conferences with his revision of the Agile Manifesto. If I’d done it, it might have been blasphemy. But he’s one of its creators, so he should know. He revised the value about working software to read:

通过工作软件(或综合文档)验证学习

Validated learning over working software (or comprehensive documentation)

如果您还记得第 3 章,经过验证的学习是来自精益创业过程的超级有价值的概念。那里的关键词是学习。使它成为有效学习的原因是讨论我们想要学习什么作为制作某物的一部分,然后回过头来考虑后果——反思我们学到了什么或没有学到什么。我们意识到的一件事是,我们并不总是需要构建软件来学习。但我们通常确实需要制作或做某事。

If you remember from Chapter 3, validated learning is the super-valuable concept that comes from the Lean Startup process. The key word there is learning. What makes it validated learning is discussing what we want to learn as part of making something, and then going back and considering the consequences—reflecting on what we learned or didn’t learn. And one of the things we’re realizing is that we don’t always need to build software to learn. But we do usually need to make or do something.

我喜欢用故事来推动我们所做的工作,以构建简单的原型,或者计划我们正在做的采访或观察用户的工作。我也喜欢谈论这些事情的人物、内容和原因。我喜欢在我们制作之前就我们将制作的东西达成一致。我回顾了这样做的后果,以考虑我们学到了什么。

I like using stories to drive the work we do to build simple prototypes, or to plan the work we’re doing to interview or observe users. I like talking about the who, what, and why for those things, too. I like agreeing on what we’ll make before we make it. And I look back at the consequences of having done it to consider what we’ve learned.

尝试使用故事来推动任何东西的制作,无论它是不是软件。

Try using stories to drive the making of anything, whether it’s software or not.

计划学习,并学会计划

Plan to Learn, and Learn to Plan

故事地图对于将我们的大产品或功能创意分解成更小的部分很有用。第 3章和第 4 章是关于将这些较小的部分分割成可构建的块,其中每个块都专注于学习一些东西。但是有一种不同的方法可以分解你需要注意的事情,并在你的头脑中保持独立。这是我们将故事分解成我们制作某物的计划的工作。这就是我们将在下一章中讨论的内容。

Story maps are useful for breaking up our big product or feature ideas into smaller parts. Chapter 3 and Chapter 4 were about slicing up those smaller parts into buildable chunks where each chunk was focused on learning something. But there’s a different way to break things down that you need to be aware of, and to keep separate in your head. It’s the work we do to break down a story into our plan to make something. That’s what we’ll talk about in the next chapter.

第 10 章像烤蛋糕一样烤故事

Chapter 10. Bake Stories Like Cake

两周前是我女儿的生日,我们想要一个蛋糕。我们家有自己的面包师——我们请他来做蛋糕。现在,我们不富裕也不害怕自己做蛋糕。只是我们的面包师 Sydnie 制作的蛋糕非常美味。我们不知道她究竟施展了怎样的烹饪魔法来实现这一目标,但每当我们问孩子们想要什么样的生日蛋糕时,他们都会大喊“我们想要一个悉尼蛋糕!” 为我们的面包师敲定交易。

Two weeks ago it was my daughter’s birthday and we wanted a cake. Our family has our own baker—a person we call to make our cakes. Now, we’re not rich or afraid to make cakes ourselves. It’s just that Sydnie, our baker, makes incredibly fantastic-tasting cakes. We don’t know exactly what culinary magic she wields to pull it off, but whenever we ask our kids what kind of cake they want for their birthday, the shout “We want a Sydnie cake!” seals the deal for our baker.

为了买蛋糕,我打电话给 Sydnie。她会问蛋糕是给谁的,是什么场合。两周前我告诉她格蕾丝快 12 岁了。“格蕾丝喜欢什么?” 她问。我们聊了聊 Grace 喜欢什么以及她在想什么。我们也聊了聊Sydnie有什么形状的蛋糕盘,她能及时准备好什么样的蛋糕设计是可行的。这次我们同意做一个鸟形蛋糕。

To get a cake, I call Sydnie on the phone. She’ll ask who the cake is for and what the occasion is. Two weeks ago I told her Grace was turning 12. “What’s Grace into?” she asks. We talk a bit about what Grace likes and what she was thinking of. We also talk about what shapes of cake pans Sydnie has, and what kind of cake design is feasible for her to have ready in time. We agree on a bird-shaped cake this time.

这就是讲故事的方式。Sydnie 问了很多关于谁、什么和为什么的问题。她询问了背景——我们将在何时何地提供蛋糕,以及那里会有多少人。在谈话中,我们考虑了几个不同的选择。我们谈了足够长的时间来建立共同的理解。而且,因为我们从 Sydnie 那里得到了很多蛋糕,所以我们已经对它们的外观和味道有了一些共同的了解。如果我们不这样做,我们会想看一些照片或品尝一些蛋糕,而手机就不能很好地满足这些需求。

That’s how telling a story works. Sydnie asked lots of who, what, and why questions. She asked about the context—where and when we’d be serving the cake, and how many people would be there. During the conversations, we considered a few different options. We talked long enough to build shared understanding. And, because we’ve gotten lots of cakes from Sydnie, we already have some shared understanding about how they’ll look and taste when we get them. If we didn’t, we’d have wanted to see some pictures or taste some cake, and the phone wouldn’t have worked well for that.

创建食谱

Create a Recipe

在我们的讨论中,Sydnie 正在考虑如何制作蛋糕。她必须这样做,这样她才能弄清楚她是否能及时赶到。到了做蛋糕的时候,她会列出一份她需要做的事情的清单——比如测量面粉、糖、黄油、鸡蛋和牛奶。她需要混合、烘烤、装饰,并可能执行其他一些我不知道的绝密步骤。我怀疑她对不同种类的蛋糕有不同的食谱,还有一张清单,列出了每个蛋糕在装进盒子准备拿走之前必须做的事情。如果 Sydnie 写下她必须做的所有事情的清单,她就会有一个充满特定蛋糕烘焙任务的工作计划。

During our discussion, Sydnie is thinking about how she’ll make the cake. She has to so she can figure out if she can make it in time. When it comes time to make the cake, she’ll have a list of things she’ll need to do—things like measuring flour, sugar, butter, eggs, and milk. She’ll need to mix, bake, decorate, and likely perform some other top-secret steps I don’t know about. I suspect she has different recipes for different kinds of cakes, and a checklist of things she has to do for every cake before it’s stuck in a box and ready to pick up. If Sydnie wrote down the list of all the things she has to do, she’d have a work plan full of specific cake-baking tasks.

没有标题的图片

当有人将故事带给开发团队时,也会发生同样的事情。他们一起决定具体要构建什么,开发团队制定他们的工作计划,由许多开发任务组成。开发团队包括测试人员、UI 设计人员、技术编写人员或创建软件所需的任何人员和技能,因此任务不仅仅与编码有关。而且,就像 Sydnie 在电话中与我交谈时没有制定她的计划一样,开发团队也不太可能在故事对话期间制定他们的计划。但他们会倾听、做笔记、画图并收集制定计划所需的大量细节。至少,这是我们希望的方式。

The same thing happens when someone brings a story to a development team. Together they make decisions on specifically what to build, and the development team creates their work plan, composed of lots of development tasks. The development team includes testers, UI designers, technical writers, or whatever people and skills are necessary to create the software, so the tasks aren’t all about coding. And, just like Sydnie didn’t create her plan while she talked with me on the phone, the development team won’t likely create their plan during the story conversation. But they will listen, take notes, draw pictures, and gather lots of the details they’ll need to create their plan. At least, that’s the way we hope it goes.

没有标题的图片

与 Sydnie 交谈时,我不会讲关于糖和面粉的故事。除非我的目标是建造一个烤箱,否则我不会讲关于烘焙的故事。当您讲述有关软件的故事并收集故事名称列表时,您在讲述故事时会想象您最终将拥有的软件。您不仅要想象软件,还要思考和谈论谁在使用它以及为什么使用它。Sydnie 并没有拘泥于蛋糕的细节,她问我蛋糕是给谁吃的,我女儿喜欢什么,聚会会有多少人,还有很多信息帮助我们一起决定最好的蛋糕应该是什么。Sydnie 不只是询问蛋糕要求,我们还共同努力决定制作我们都喜欢的蛋糕的最佳方式。这就是故事对话背后的真正精神。

When talking with Sydnie, I don’t tell stories about cups of sugar and flour. I wouldn’t tell a story about baking unless my goal was to build an oven. When you tell stories about software, and collect a list of story names as you do, you tell the story imagining the software you’ll have in the end. And you don’t just imagine the software—you think and talk about who uses it and why. Sydnie didn’t just stick to details about the cake, she asked me who it was for, what my daughter liked, how many people would be at the party, and lots of information that helped us decide together what the best cake should be. Sydnie wasn’t just asking for cake requirements, we were working together to decide on the best way to create a cake we’d all love. That’s the real spirit behind a story conversation.

打破一个大蛋糕

Breaking Down a Big Cake

但只有一件事。这里经常出现的问题是,当我们开始向真正有能力将我们的愿景变为现实的人讲述这个故事时,我们很快就会发现我们的故事所描述的软件非常庞大。好吧,上面写着它的卡片和其他卡片一样大。我们的用户试图通过它达到的目标对他们来说可能并不比其他人更重要,但是当我们谈论它时,我们意识到编写实现该目标所需的软件需要花费大量时间。

But there’s just one thing. Often what goes wrong here is that, when we start telling the story to people who are really capable of turning our vision into reality, we quickly figure out that the software our story describes is really big. Well, the card it’s written on is the same size as all the others. And the goal our users are trying to reach with it may be no more important to them than others, but it’s when we talk about it that we realize it’ll take a lot of time to write the software necessary to reach that goal.

当我和 Sydnie 谈论我的蛋糕时,同样的事情也可能发生。我本可以想象一个精致的蛋糕需要 Sydnie 没有的蛋糕盘,或者她没有掌握的蛋糕制作和装饰技术。结果将是一个我买不起的蛋糕,而且 Sydnie 也无法在我女儿生日前送出。

The same thing could have happened when I was talking with Sydnie about my cake. I could have imagined an elaborate cake that calls for cake pans Sydnie doesn’t have, or cake-building and decorating techniques she’s not mastered. The result would be a cake I can’t afford, and one that Sydnie couldn’t predictably deliver before my daughter’s birthday.

第 7 章中,我指出,当我们考虑的解决方案过于昂贵时,我们需要退后一步,真正审视我们正在努力解决的问题,以及我们正在努力实现的结果。我们需要考虑其他选择。这是获得较小蛋糕或馅饼的一种方法?

In Chapter 7, I pointed out that when the solution we’re thinking of is too expensive, we need to step back and really look at the problems we’re trying to solve, and the outcomes we’re trying to achieve. And we’ll need to consider other alternatives. That’s one way to get a smaller cake—or maybe a pie?

如果故事描述的解决方案成本太高,请考虑另一种可以帮助您实现目标的解决方案。

If the story describes a solution that’s too expensive, consider a different solution that helps you reach the goal.

但是,如果它真的很大,而且我们负担得起,那么就没有理由把它分解得更小,对吧?好吧,实际上是有的。对于软件,尤其是通过将事物分成更小的部分来构建,我们可以更快地看到和衡量进展。这有助于花钱的人不那么紧张。而且,就像第 4 章蒙娜丽莎策略一样,它可以帮助制造产品的人评估零件,以确保我们走在正确的轨道上。

But, if it’s really big, and we can afford it, then there’s no reason to break it down any smaller, right? Well, actually, there is. With software, especially, by building things in smaller parts, we can see and measure progress sooner. This helps the people spending money feel a bit less nervous. And, as in Chapter 4’s Mona Lisa strategy, it helps the people making the product evaluate parts to make sure we’re on the right track.

如果故事描述了一个经济实惠但规模庞大的解决方案,请将其分解成更小的部分,以便您能够更快地进行评估和看到进展。

If the story describes a solution that’s affordable but big, break it into smaller parts that allow you to evaluate and see progress sooner.

有一个分解大故事的技巧,它可以帮助我在脑海中记住蛋糕的比喻。如果你喜欢蛋糕,现在你可能会饿了——尤其是当你想象中的蛋糕特别好吃的时候。对于那个很抱歉。

There’s a trick to breaking down large stories, and it helps me to keep the cake metaphor in my head. If you like cake, by now you might be getting hungry—especially if the cake you’re imagining is a particularly tasty one. Sorry about that.

假设我们的故事描述了对更大蛋糕的需求,例如可以供数百人食用的超大婚礼蛋糕。如果是这样,那么它不再只是几杯面粉和糖,而是麻袋面粉和糖。大多数人以同样的方式分解软件。不仅仅是一点用户界面、一点业务逻辑和一点数据库交互,每个都有很多。但请记住,软件不是蛋糕。量两磅面粉所花的时间并不比量两杯面粉所花的时间多。但是为 20 个屏幕构建用户界面比仅仅为 2 个屏幕构建用户界面要花费更多的时间。因此,如果团队使用看似合乎逻辑的简单分解结构,他们很容易将软件分解为数周的前端开发、数周的业务逻辑开发等。当我们使用该策略时,我们需要很长时间才能“尝到任何蛋糕”,可以这么说。所以不要那样做。

Let’s say our story describes a need for a lot bigger cake, like a super-giant wedding cake that will feed hundreds of people. If so, then it isn’t just cups of flour and sugar anymore, it’s sacks of flour and sugar. Most people break down software the same way. Instead of just a little user interface, a little business logic, and a little database interaction, there’s lots of each. But remember that software isn’t cake. It doesn’t take that much more time to measure two pounds of flour than it does to measure two cups of flour. But building the user interface for 20 screens takes a lot more time than for just 2 screens. So, if teams use the simple breakdown structure that seems logical, they get tempted to break software down into weeks of frontend development, weeks of business logic development, and so on. When we use that strategy, it takes a long time before we can “taste any cake,” so to speak. So don’t do that.

不要把大事分解成大计划。用小计划将大事化为小事。

Don’t break down big things into big plans. Break big things into small things with small plans.

现在这个比喻真的要在这里崩溃了,但再坚持一分钟。处理一个大软件蛋糕的方法是将它分解成许多小蛋糕。每一个都是可交付的,每一个都有相似的食谱,加一点糖,一点面粉,一两个鸡蛋,等等。

Now the metaphor is really going to break down here, but stick with me for just one more minute. The way you approach a big software cake is to break it down into lots of little cupcakes. Each one is deliverable, and each one still has a similar recipe, with a little sugar, a little flour, an egg or two, and so on.

没有标题的图片

好的,现在让我们再认真一点。软件不是蛋糕。它可能变得巨大、极其昂贵且风险极大。在我撰写本文时,我刚刚在早间电视新闻中听到另一个故事,即美国政府未能通过网站为人们注册医疗保健。事后批评很容易。但也很容易看出,在比喻婚礼上送蛋糕之前,没有人尝过蛋糕——至少没有人尝过。那个半生不熟的蛋糕毁了聚会。

OK, now let’s get a little more serious again. Software isn’t cake. It can get huge, horrendously expensive, and horribly risky. As I write this text, I’ve just heard yet another story on the morning television news of the US government’s failed website to sign people up for healthcare. It’s easy to criticize after the fact. But it’s also easy to see that no one tasted that cake before it was served at the metaphoric wedding—at least no one with any taste. And that half-baked cake ruined the party.

如果您在更传统的软件开发领域工作过一段时间,您可能学会了将大型软件分解为大型计划。我知道我做到了。将大的东西分解成看起来不太像您要交付的成品的小块似乎有悖常理。您会知道,在组合这些软件部分时,您必须对每个部分进行一些重写和调整才能将它们组合起来。但请记住——您有很多充分的理由这样想。最大的挑战之一是避免因太晚未看到、使用或“品尝”软件而带来的风险。你正在把大事分解成小的、可评估的部分,这样你就可以更快地学习。

If you’ve worked in more traditional software development for a while, you likely learned to break down big software into big plans. I know I did. It’ll seems counterintuitive to break down something big into smaller pieces that may not quite look like the finished product you’re trying to deliver. You’ll know that as you combine these pieces of software, you’ll have to do a bit of rewriting and adjusting of each piece to combine them. But remember—you’re thinking this way for lots of good reasons. One of the biggest is to avoid the risks involved with not seeing, using, or “tasting” the software too late. You’re breaking big things down to small, evaluable parts so you can learn sooner.

如果我分解蛋糕的目的是为了早点品尝它或早点看到装饰,我最好烤一些小纸杯蛋糕来帮助我更快地学习。我会烤一些不同口味的,这样我就可以品尝到所有的口味,选择我最喜欢的,并确信我做出了正确的选择。如果我关心颜色和装饰,我会想看看不同风格装饰的不同纸杯蛋糕,然后选择最好的那一款。

If I were breaking down a cake with the goal of tasting it sooner or seeing the decoration sooner, I’d do well to bake small cupcakes that help me learn sooner. I’d bake some in a number of different flavors so I could taste them all, choose the one I liked best, and be confident I’d made the right choice. If I were concerned about colors and decoration, I’d want to look at different cupcakes decorated in different styles, and choose the one that was best.

对于软件,纸杯蛋糕是工作软件的一部分,允许用户评估他们是否可以有效地完成用户任务。它们可能是帮助暴露技术风险的软件部分。但是每件作品都可以帮助我们学到一些东西。

With software, the cupcakes are portions of working software that allow users to evaluate if they can effectively complete a user task. They may be portions of software that help expose a technical risk. But each piece helps us learn something.

但是一堆纸杯蛋糕不是结婚蛋糕——是吗?[ 11 ]

But a pile of cupcakes isn’t a wedding cake—or is it?[11]

没有标题的图片

软件不是蛋糕。我们构建的每个软件都以一种蛋糕无法做到的方式组合成一个更大的工作产品

Software isn’t cake. And every piece of software we build does combine into one larger working product in a way that cake can’t.

我的朋友 Luke Hohman 有一句愚蠢的口头禅是你可以送“半个烤蛋糕,而不是半生不熟的蛋糕”。半个烤好的蛋糕可能不足以满足一场婚礼的需要,但足以让每个人品尝并期待剩下的蛋糕。

One of the silly mantras that comes from my friend Luke Hohman is that you can deliver “half a baked cake, not a half-baked cake.” Half a baked cake may not be enough to feed a wedding party, but it’s enough to taste and leave everyone looking forward to the rest of the cake.




[ 11 ]玛丽的结婚蛋糕(照片由 Mary Treseler 提供)。

[11] Mary’s wedding cake (photo courtesy of Mary Treseler).

第 11 章岩石破碎

Chapter 11. Rock Breaking

故事的最初想法非常简单——在卡片上写点东西,讨论它,然后就构建什么达成一致。然后,通过构建它并从您构建的内容中学习来完成循环。就是这样——非常简单,对吧?如果您参与软件开发的时间很短,您就会知道没有那么简单。故事经历了一段漫长的旅程,其中涉及很多人的大量对话,将产品、功能或增强功能的想法转移到您的产品中,然后将该产品推向市场。好消息是你可以全程使用故事和讲故事。我保证依靠故事和讲故事帮助你一路走来。

The original idea of stories was pretty simple—write something on a card, talk about it, and agree on what to build. Then, complete the cycle by building it and learning from what you’ve built. That’s it—pretty straightforward, right? If you’ve been involved in software development for even a small amount of time, you know nothing is that simple. Stories go through a long journey with lots of conversations involving lots of people to move an idea for a product, feature, or enhancement into your product, and then move that product out to market. The good news is you can use stories and storytelling all the way through. And I promise that relying on stories and storytelling will help you all the way through.

尺寸总是很重要

Size Always Matters

我通过谈论 Sydnie 的蛋糕和突破的想法结束了最后一章蛋糕变成小蛋糕。但软件的有形性要差得多,而且尺寸不能像蛋糕那样以英寸、厘米、盎司或克来衡量。

I ended the last chapter by talking about Sydnie’s cake and the idea of breaking big cakes into little cakes. But software is a lot less tangible, and size can’t be measured in inches, centimeters, ounces, or grams like it can with a cake.

最初的想法是,用户或需要某物的人可以在卡片上写下他需要的东西,然后我们可以就此进行对话。需要它的人不知道如何将他的需求表达为只需要很短时间就能形成的东西。它需要大小。

The original idea was that a user or a person who needs something could write what he needed on a card and then we could have a conversation about that. The person who needed it didn’t figure out how to express his need as something that would take only a short time to develop. It was need sized.

从用户的角度来看,大小合适的故事是满足需求的故事。

A right-sized story from a user’s perspective is one that fulfills a need.

到了编写软件的时候,编写、测试和集成软件的小部分有很大好处。如果我能更快地看到和测试小零件,我就能衡量我们建造的速度和我们获得的质量。如果我可以将大的东西分成许多小的部分,那么我的团队就可以更容易地同时挑选和构建零件。一个好的经验法则是将故事分解成需要几天时间来构建和测试的东西。

When it comes time to write software, there’s big benefit in writing, testing, and integrating software in small parts. If I can see and test small parts sooner, I can measure how fast we’re building and what kind of quality we’re getting. If I can divide something big into lots of smaller parts, it makes it a little easier for my team to pick up and build parts concurrently. A good rule of thumb is to break down stories to something that takes a couple of days to build and test.

从开发团队的角度来看,一个大小合适的故事只需要几天的时间来构建和测试。

A right-sized story from a development team’s perspective is one that takes just a few days to build and test.

但是,从商业角度来看,以多种功能捆绑的形式向客户和用户发布软件可能是最有意义的。如果您要发布一个全新的产品,那么第一个捆绑包可能会非常大。这是我之前称为最小可行解决方案的捆绑包,它专注于为目标用户群实现特定结果。理想情况下,企业应该努力更频繁地发布更多这些内容——以推动它们更接近于匹配用户的需求规模,或者更小、更具体的业务成果。但是,如果您有大量不同的客户使用您的产品,并且您没有支持更连续的发布过程的基础架构或业务模型,那么您的业务发布可能会更大。

But, from a business perspective, it may make the most sense to release software to customers and users in bundles of multiple features. If you’re releasing a whole new product, that first bundle can be pretty large. This is the bundle I called a minimum viable solution earlier, and it’s focused on reaching specific outcomes for a target group of users. Ideally, businesses should be striving to release more of these more frequently—to push them closer to matching users’ need size, or a smaller and more specific business outcome. But, if you’ve got a large, diverse group of customers using your product, and you don’t have an infrastructure or business model that supports a more continuous release process, then your business’s releases may be bigger.

从业务角度来看,大小合适的故事可以帮助企业实现业务成果。

A right-sized story from a business perspective is one that helps a business achieve a business outcome.

我可以说故事没有“合适的大小”,但事实并非如此。合适的尺寸是与您正在进行的对话相关的尺寸。

I could say there’s no “right size” for stories, but that’s not true. The right size is the size that’s relevant to the conversation you’re having.

没有标题的图片

这些大故事包含许多小故事,小故事又包含更多小故事。根据您的谈话对象,您可能必须将谈话“卷起”到更高的层次。

Those big stories contain lots of smaller stories, which in turn contain lots more smaller stories. Depending on who you’re talking to, you might have to “roll up” your conversation to a higher level.

故事像石头

Stories Are Like Rocks

把故事想象成岩石。如果我拿一块非常大的石头,把它放在地板中间,然后用木槌敲打它,让它裂成 30 块,我们就称那 30 块石头为石头。如果你拿起其中一块较小的石头并用木槌敲打它,它就会碎成小块。我们也称这些作品为岩石。现在,我们可能会对给这些岩石起的名字变得有创意,比如boulderpebble。但我不确定什么时候某样东西不再是一块巨石,而开始只是一块普通的老石头。它看起来像一块石头,直到它落在你的脚上。然后感觉就像一块巨石。

Think of stories like rocks. If I were to take a really big rock and put it in the middle of the floor and hit it with a mallet where it broke into 30 pieces, we’d call those 30 pieces rocks. If you took one of those smaller rocks and hit it with a mallet, it would break into smaller pieces. We’d call those pieces rocks, too. Now, we might get creative about the names we give these rocks, like boulder or pebble. But I’m never sure when something stops being a boulder and starts being just a plain old rock. It looks like a rock until it’s dropped on your foot. Then it feels like a boulder.

没有标题的图片

我的破石工具是一把大木槌。这很有效。

My rock-breaking tool is a big mallet. And that works pretty well.

大故事分解成小故事,小故事又可以分解成更小的故事。就像岩石一样。而且,无论大小如何——无论多小——它们仍然是一个故事。但是,我们用来分解故事的最佳工具是什么?没错:这是对话。有时只需要一点点思考就可以做到,但如果您与其他人进行对话和协作,那么您就是在传播共同的理解。

Big stories break down into smaller stories, and those smaller stories can be broken down to even smaller stories. Just like rocks. And, at every size—no matter how small—they’re still a story. But what’s the best tool we use for breaking down stories? That’s right: it’s conversation. Sometimes just a little thinking will do it, but if you use conversation and collaboration with someone else, then you’re spreading the shared understanding.

对话是分解大故事的最佳工具之一。

Conversations are one of the best tools for breaking down big stories.

现在软件人员,我也是其中之一,对这里缺乏精确性感到不舒服。在我合作过的大多数组织中,都会出现按大小对故事进行分类的语言。但它又开始提出“巨石与鹅卵石”的问题。当你是一个被石头砸中的人时,关于大小的精确度最重要,这可以解释为什么软件人员热衷于对他们的故事进行分类。

Now software people, and I’m one of them, are uncomfortable with the lack of precision here. In most organizations I’ve worked with, language will emerge to classify stories by size. But it starts to raise the “boulders versus pebbles” question again. The precision about size matters most when you’re the one being hit with the rock, which could explain why software people get wrapped up in classifying their stories.

没有标题的图片

如果你在你的组织中创造语言,不要试图过于精确。关于故事中的内容以及它应该有多大的摆动是有意的。它为我们提供了在整个开发周期中使用这个简单想法所需的灵活性。

If you create language in your organization, don’t try to be too precise. The wiggliness about what’s in a story and how big it should be is intentional. It gives us the flexibility we need to use this simple idea throughout the development cycle.

史诗是有时用来打人的大石头

Epics Are Big Rocks Sometimes Used to Hit People

史诗是一个常用术语(我不确定最初是谁创造的)用于描述大用户故事,有点像boulder是大石头的好用词。老实说,我花了很多年才习惯将我们正在构建的重要内容称为故事,但我现在明白为什么要这样称呼它们了。我仍在为epic一词而苦苦挣扎。我听到我的英语文学老师将史诗描述为一个英雄与邪恶作战的故事——比如贝奥武夫、阿喀琉斯或佛罗多——通常是在某种魔法武器或众神的帮助下。但是,我离题了……

Epic is a common term (I’m not sure who coined it originally) used to describe big user stories, sort of like boulder is a good term for a big rock. Now I’ll be honest with you that it took me years to get comfortable referring to the important stuff we were building as stories, but I understand now why they’re called that. I’m still struggling with the term epic. I hear my English Literature teacher describing an epic as a story about a hero battling evil—like Beowulf or Achilles or Frodo—usually with some sort of magic weapon or the assistance of the gods. But, I digress…

史诗是一个我们期望很大的故事,并且知道需要分解。

An epic is a story that we expect is large, and know needs to be broken down.

为一个大故事取一个术语是可以的,但要小心。史诗一词有时被用作武器。我经常看到一个开发团队成员告诉某个业务人员、产品经理、用户或有求必应的人,他的故事是史诗,而不是故事。这通常是以一种表明故事作者做错了什么的语气说的,导致她认真考虑对开发团队成员进行打击。所以,如果你是团队成员,请不要用史诗这个词来训斥别人。对于应该富有成效的对话来说,这是一个糟糕的开始(而且可能是过早的结束)。

It’s OK to have a term for a large story, but watch out. The term epic sometimes gets used as a weapon. I’ve often seen a development team member tell someone who is a businessperson, a product manager, a user, or someone who’s asking for something, that his story is an epic, not a story. This is usually said in a tone that indicates the storywriter has done something wrong, causing her to seriously consider sucker-punching the development team member. So, please, if you are a team member, don’t use the term epic as a stick to reprimand someone else. It’s a bad start (and, possibly, a premature ending) to what should be a productive conversation.

没有标题的图片

请记住,史诗是大故事,从业务、客户或用户的角度来看可能大小合适——而不是从开发的角度来看。共同努力打破他们。但是要保留史诗,因为你需要和人们谈论它,以及它分解成的所有详细故事。

Remember, epics are big stories that may be the right size from a business, customer, or user perspective—just not from a development perspective. Work together to break them down. But keep the epic around because you’ll need to speak to people about it, and all the detailed stories it broke down into.

如果您使用的是支持敏捷开发的电子工具,它可能会使用史诗的概念作为可以拆分为许多较小的子故事的大父故事。

If you’re using an electronic tool that supports Agile development, it’ll likely use the concept of an epic as a big parent story that can be split up into lots of smaller child stories.

主题组织故事组

Themes Organize Groups of Stories

使用术语主题来描述一组故事,将它们组合在一起很有用。当你开始打破常规——分解那些大故事并将它们组织成人们想要、可以使用并且有能力建造的产品——你最终会得到许多小故事。我认为主题是一个袋子,我可以用它来收集一堆相关的故事。我可以使用主题来收集下一个版本所需的一堆故事、同一功能的一部分、与特定类型的用户相关或以其他方式相关。但我的比喻有点不对劲,因为同一个故事可以有两个不同的主题,但同一块石头不能放在两个不同的袋子里。

Use the term theme to describe a group of stories that it’s useful to group together. As you start rock breaking—breaking down those big stories and organizing them into products that people want, can use, and can afford to build—you’ll end up with lots of smaller stories. I think of a theme as a sack I can use to collect a pile of stories that are related. I could use a theme to collect a bunch of stories that are needed for a next release, part of the same feature, relevant to a particular type of user, or related in some other way. But my metaphor is slightly broken since the same story can be in two different themes, but the same rock can’t be in two different sacks.

没有标题的图片

如果您使用帮助组织敏捷故事组的可用工具之一,它可能支持将故事捆绑成一个主题的概念。您可能只是根据主题的实际情况来引用主题:您的下一个版本、功能或与特定类型用户相关的故事。

If you use one of the available tools that help organize groups of Agile stories, it may support the concept of bundling stories up into a theme. You might simply refer to the theme by what it really is: your next release, the feature, or the stories relevant to a particular type of user.

忘掉那些术语,专注于讲故事

Forget Those Terms and Focus on Storytelling

术语史诗主题已经进入敏捷生命周期管理工具,进入一些特定的命名敏捷方法,并进入用于讨论故事的通用语言。因此,您需要了解并理解它们。

The terms epic and theme have found their way into Agile lifecycle management tools, into some specific named Agile approaches, and into the common language used to discuss stories. For that reason, you’ll need to know and understand them.

现在,让我们搁置这些条款;忘了我什至提到过他们。至少有一小会儿。让我们退后一步,看看整个破土动工的生命周期。在那个周期中,我们将从大创意开始,您可以将其视为大石头,然后将它们一直移动到小块工作软件。然后将这些小块的工作软件重新组合成客户和用户想要的功能、产品和版本。

Now, let’s set aside those terms; forget I even mentioned them. At least for a little while. Let’s step back and take a look at the whole rock-breaking lifecycle. In that cycle we’ll start with big ideas, which you can think of as the big rocks, and move them all the way through to small pieces of working software. And then reassemble those small pieces of working software into features, products, and releases that customers and users want.

从远处看,这个破岩循环看起来像这样:

From a distance, that rock-breaking cycle looks like this:

没有标题的图片

现在,让我们深入了解细节。

Now, let’s dig into the details.

从机会开始

Start with Opportunities

故事的旅程始于一个想法。它可能是新功能或全新产品的想法。这可能是我们希望改进我们已有功能的更改。这可能是我们需要解决的问题。但我会使用机会这个词,因为它是我们创造我们将从中受益的东西的机会。我建议您列出并列出这些机会。我称它们为机会积压

The story’s journey starts as an idea. It may be an idea for a new feature, or a whole new product. It could be a change we’d like that would improve a feature we already have. It could be a problem we need to solve. But I’ll use the term opportunity, because it’s an opportunity for us to make something that we’ll benefit from. I suggest you name and build a list of these opportunities. I call them an opportunity backlog.

没有标题的图片

我们的第一个好故事对话是一个更高层次的、谁-什么-为什么的讨论。我们的大目标是做出走/不走的决定。Go 并不意味着我们会构建它。这意味着我们将继续进行更深入的讨论,以真正理解这个故事。但如果我们从一开始就发现这是个坏主意,我不想继续花费大量时间来做这件事。No-go 是一种礼貌的表达“垃圾”的方式。所以,让我们称之为前进/垃圾决定。记住,总是有太多东西需要建造,在浪费每个人太多时间之前扼杀一个平庸的机会应该值得庆祝。

Our first good story conversation is a higher-level, who-what-why discussion. And our big goal is to make a go/no-go decision. Go doesn’t mean we’ll build it. It means we’ll go forward with deeper-dive discussions to really understand the story. But I don’t want to move forward with spending lots of time doing this if we can detect that it’s a bad idea from the outset. No-go is a polite way of saying “trash.” So, let’s call this a go-forward/trash decision. Remember, there’s always too much to build, and killing a mediocre opportunity before it wastes too much of everyone’s time should be celebrated.

利用机会讨论来同意问题值得解决——做出继续或垃圾决定。

Use opportunity discussions to agree the problem is worth solving—to make a go-forward or trash decision.

发现最小可行解决方案

Discover a Minimum Viable Solution

既然您已选择继续前进,那么是时候进行更深入的挖掘了。使用发现来找到值得构建的解决方案。并且不要忘记真正最小化该解决方案。力求使它尽可能小而有价值。

Now that you’ve chosen to go forward, it’s time to dig much deeper. Use discovery to find a solution worth building. And don’t forget to really minimize that solution. Seek to make it as small and valuable as you can.

没有标题的图片

在发现过程中,您将真正深入挖掘:

During discovery you’ll really dig deep into:

  • 您认为哪些客户和用户会使用您的解决方案
  • Who the customers and users are you believe will use your solution
  • 如果没有您的解决方案,他们如何满足今天的需求
  • How they meet their needs today without your solution
  • 您的解决方案将如何为他们改变世界
  • How the world would change for them with your solution
  • 您的解决方案的外观和行为
  • How your solution might look and behave
  • 您的解决方案可能需要多长时间才能构建
  • How long your solution might take to build

有大量的实践可以在发现过程中提供帮助,尤其是故事映射。故事映射可以帮助您了解当今人们的工作方式,然后映射您关于创建解决方案后事情将如何改变的想法。

There are a huge number of practices that can be helpful during discovery, especially story mapping. Story mapping can help you understand how people work today, and then map your ideas about how things will change for them after your solution is created.

发现是认真研究我们的假设并努力验证它们的关键所在。这可能会采取更深入的分析形式,以了解业务规则或外部法规。它应该采取直接花时间与客户和用户交流的形式,以了解他们的工作方式。它应该涉及构建解决方案的原型并与目标受众一起验证它们。它还应包括构建技术原型以排除技术风险。

Discovery is where it’s critical to look hard at our assumptions and to do work to validate them. This may take the form of deeper analysis to understand business rules or outside regulations. It should take the form of spending time directly with customers and users to understand how they work. It should involve building prototypes of your solution and validating them with your target audience. And it should include building technical prototypes to chase out technical risks.

使用发现对话和探索来找到一个小的、可行的解决方案。

Use discovery conversations and exploration to find a small, viable solution.

庆祝该解决方案中您可以安全丢弃的每一部分,或者将积压的机会推迟到其他地方处理。我们的机会可能是大石头。但这些岩石里面是钻石和贵金属。分解那些石头,把那些真正有价值的部分从那些只是石头的东西中分离出来。并庆祝扔掉那些东西。

Celebrate every part of that solution that you can safely trash, or push back to a backlog of opportunities to deal with elsewhere. Our opportunities may have been big rocks. But inside those rocks were diamonds and precious metals. Break down those rocks and separate those really valuable parts from the stuff that’s just rock. And celebrate trashing that stuff.

在整个发现过程中,您可以选择构建有助于您学习的小东西——特别是 UI 或架构原型。

Throughout discovery, you may choose to build small things that help you learn—specifically, UI or architectural prototypes.

Spike是一个术语,用于表示我们以明确的学习目标进行的一些开发或研究。这是一个来自极限编程社区的术语,用于描述可能不会产生我们选择发布的软件的工作。使用故事来描述让你的团队构建一些东西来学习的峰值。

Spike is a term used for bits of development or research we do with the explicit goal of learning. It’s a term that came from the Extreme Programming community to describe work that may not yield software we choose to ship. Use stories to describe spikes that get your team building something to learn.

在您确信您已经获得了应该构建并发布给客户和用户的故事的一小部分之后,就该将它们推进到交付阶段了。导致有价值的产品发布的故事子集就是我所说的发布积压

After you’re confident you’ve got that small subset of stories you should build and release to customers and users, then it’s time to move them forward into delivery. That subset of stories that leads to a valuable product release is what I refer to as a release backlog.

在交付过程中深入了解每个故事的细节

Dive into the Details of Each Story During Delivery

我们的机会可能始于大石头。发现对话打破了它们并将岩石与贵金属分开。但是,如果我们能够将这些部分分解成尽可能小的部分,那么交付将以最快和最有效的方式进行——请记住,每个部分仍然需要是我们可以构建和学习的东西。要做到这一点,需要进行更多的对话,深入得多。

Our opportunities may have started as big rocks. Discovery conversations broke them down and separated the rock from the precious metals. But delivery will move fastest and most effectively if we can keep breaking down those pieces into the smallest parts possible—keeping in mind that every part still needs to be something we can build and learn from. It’s going to take a lot more conversations that dive into a lot more depth to do that.

没有标题的图片

我想象一台很酷的岩石破碎机:我在一侧装载这些包含所有贵金属的大而粗糙的岩石,然后在另一侧吐出大小恰到好处的小岩石,准备进入下一个开发周期。我要给这台机器贴上故事车间机器的标签,它的名字准确地描述了我们将要做的事情。

I picture a cool rock-breaking machine: on one side I load these big, rough rocks that contain all those precious metals, and then the other side spits out small, just-right-sized rocks ready to go into the next development cycle. I’m going to label this machine the story workshop machine, and its name describes exactly what we’ll do.

我们将与开发人员和测试人员以及团队中将构建软件的其他人进行深入讨论,以真正挖掘细节。这些是我们“最后的最佳对话”——我们真正需要就确认达成一致的对话,或我们构建的软件的小部分的验收标准——因为下一步是构建它们。因为我们知道它是打破软件的对话,所以我们将使用这些对话将我们的故事调整到合适的大小和形状,以放入下一个开发冲刺或迭代。

We’ll use deep-dive discussions with developers and testers, and everyone else on the team who’ll build the software, to really dig into the details. These are our “last best conversations”—the conversations where we really need to agree on confirmation, or the acceptance criteria for the small parts of software we build—because the next step is building them. Since we know that it’s conversations that break up software, we’ll use these conversations to get our stories into the right size and shape to put into the next development sprint, or iteration.

使用深度故事研讨会来讨论细节、分解故事,并就我们将要构建的具体内容达成真正一致。

Use deep-dive story workshops to discuss the details, break down stories, and really agree on specifically what we’ll build.

我喜欢将这些最后的最佳故事对话称为故事工作坊,因为每个人都知道会议没有效率,但研讨会是为了完成工作。它们可以根据需要发生,几乎每天都会发生。有时它们会在计划会议期间同时发生。在敏捷流程 Scrum 中,它们可能发生在所谓的待办事项梳理待办事项改进会议期间。不管你怎么称呼这些讨论,都进行讨论。

I like to call these last best story conversations story workshops because everyone knows that meetings are unproductive, but workshops are for getting work done. They can happen as needed, almost every day. Sometimes they happen all at once during a planning session. In the Agile process Scrum, they may happen during what’s called a backlog grooming or backlog refinement session. Whatever you call these discussions, have them.

在构建过程中保持对话

Keep Talking as You Build

故事车间机器为下一个生产线——敏捷交付机器提供动力。这就是我想象的敏捷交付机器真正发挥作用的地方。我们在一侧放置这些小的、常规大小的故事,而在另一侧放出一个经过优化的、可工作的软件——或者你的故事所描述的任何东西。

The story workshop machine feeds the next in line—the Agile delivery machine. And here’s where I picture the Agile delivery machine really kicking in. In one side we put these small, regular-sized stories, and out the other side comes a polished, working bit of software—or whatever it is that your story described making.

无论您多么努力,即使是您最近的最佳故事对话也无法预测您在开始构建后将学到的一切。计划每天进行大量频繁的临时故事对话。在日常站立会议中提出对它们的需求。

No matter how hard you try, even your last best story conversations won’t have predicted everything you’ll learn once you start to build. Plan to have lots of frequent, ad hoc story conversations every day. Bring up the need for them in your daily standup meetings.

没有标题的图片

如果您是一名开发人员,并且您陷入故事讨论中的细节不足以回答您现在的问题,请跳起来找人交谈以继续您的讨论。你不能在这里责怪糟糕的要求。请记住,在开始之前,您与其他人一起确定了构建所需的所有知识。但我们都是人。错过一些东西是可以的。

If you’re a developer and the details you trapped in story discussions aren’t enough to answer questions you have now, jump up and find someone to talk with to continue your discussion. You can’t blame bad requirements here. Remember that, before you started, you worked with others to identify all you’d need to know to build. But we’re all human. It’s OK to miss some things.

如果您是产品负责人、用户体验设计师、业务分析师或其他帮助决定构建内容的人之一,请不要害怕从办公桌上站起来查看开发进展情况。我保证,一旦您看到有用的东西,您就会看到有用的东西。而且,更有可能的是,使它工作的人可以使用一点反馈。

If you’re a product owner, UX designer, business analyst, or one of the other folks who helped decide what to build, don’t be afraid to get up from your desk to see how development is going. I promise that once you see something working, you’ll see something useful. And, more than likely, the person getting it working could use a little feedback.

在构建过程中使用对话来填写详细信息并对正在构建的内容提供反馈。

Use conversations as you build to fill in details and give feedback on what’s being built.

评估每件作品

Evaluate Each Piece

当那些完成的工作软件从敏捷交付机器中滚出来时,是时候让那些帮助描述要构建什么的人和构建它的人停下来仔细看看我们构建的东西了。

When those finished bits of working software roll out of the Agile delivery machine, it’s time for the people who helped describe what to build, and the people who build it, to pause and look closely at what we built.

请记住,这些并不是真正的机器。你和你的同事都不是机器上的齿轮。而你刚刚发现的所有这些部分并不是完全相同的小部件。他们都是不同的。

Remember, these aren’t really machines. And you and the people you work with aren’t cogs in a machine. And all those pieces you just turned out aren’t exactly the same widget. They’re all different.

没有标题的图片

停下来真正看看构建的解决方案的质量。反思你的计划有多有效。你真的完成了你的预期吗?需要更长的时间吗?更短?或者关于你的想象?并真正谈论“机器”的工作情况。是时候对您的工作方式进行调整或改变,以更可预测地获得质量更好的东西了。

Stop and really look at the quality of the solution built. Reflect on how effectively you planned. Did you really finish what you expected? Did it take a lot longer? Shorter? Or about what you imagined? And really talk about how well the “machine” is working. It’s time to make adjustments or changes to the way you work to get better-quality stuff out more predictably.

经常反思产品质量、您的计划和您的工作方式。

Frequently reflect on product quality, your plans, and the way you work.

Scrum 中的第一次评估称为冲刺评审和回顾。无论您将这些时间称为停下来、回顾和反思,请确保您拥有它们。

This first pass at evaluation in Scrum is called a sprint review and retrospective. Whatever you call these times to stop, review, and reflect, make sure you have them.

与用户和客户一起评估

Evaluate with Users and Customers

请记住,您正在构建的内容不适合您——至少通常不适合您。您需要将它展示在用户和客户面前,以了解他们的感受。对于这些人中的一些人,他们所看到的只是原型、线框图或文字描述。看到和触摸到有用的东西,真的可以让他们评估自己是否得到了正确的东西。

Remember that what you’re building wasn’t for you—at least not usually. You’ll need to get it in front of users and customers to see how they feel about it. For some of these folks, all they’ll have seen is a prototype, or a wireframe, or a textual description. Seeing and touching something working really lets them evaluate whether or not they’ve got the right thing.

但是从敏捷交付机器中出来的这些小碎片中的每一个都可能不足以让他们分辨。在我的心智模型中,我想象每一块都在一个秤上堆积起来。这是一种老式秤,另一边有配重。在我的配重上是足够的这个词;也就是说,足以与用户和客户进行测试,并让他们和我们学到一些东西。

But each of these little pieces that came out of the Agile delivery machine may not be enough for them to tell. In my mental model I picture each of those pieces piling up on a scale. It’s one of those old-style scales with a counterweight on the other side. On my counterweight is the word Enough; that is, enough to test with users and customers and for them and us to learn something.

没有标题的图片

通常足够意味着整个屏幕或屏幕流,允许用户完成任务或达到有意义的目标。而且我不想做一个节目并告诉用户。我不是要他们说,“那太好了。” 我正在寻求学习——学习的形式通常是“这不太对”和“现在我真的在使用它,如果……会更好”

Usually enough means a whole screen, or a flow of screens, that allows users to complete a task or reach a meaningful goal. And I don’t want to do a show and tell with users. I’m not looking for them to say, “That’s great.” I’m looking to learn—and learning usually takes the form of “That’s not quite right” and “Now that I really use it, it would be better if…”

通过与客户和用户一起测试有意义的工作软件块来学习。

Learn by testing meaningful chunks of working software with customers and users.

与业务利益相关者一起评估

Evaluate with Business Stakeholders

您的组织中可能还有其他人对您正在构建的软件有既得利益。他们可能不是每天都会使用它的人,但他们担心软件会尽快交付给这些人——或者至少在你说的时候。

There are likely others in your organization who have a vested interest in the software you’re building. They may not be the people who’ll use it every day, but they’re concerned that the software is going to be delivered to those people as soon as possible—or at least when you said it would be.

没有标题的图片

使用评论向他们展示到目前为止的产品。使用评论来谈论您与更大计划的关系。请记住:他们可能对您是否满足了您构建的一堆单个小零件的计划不感兴趣。他们感兴趣的是最小可行解决方案的进展——因为这是我们可以发布并真正从外部世界获得一些价值的最小部分。所以说那个。与他们分享您对用户或客户进行的测试的结果。他们也会有兴趣了解这一点。

Use a review to show them the product so far. Use the review to talk about where you are in relationship to your bigger plan. Remember: they likely aren’t interested in whether you meet your plan for the bunch of single, small parts you built. What they’re interested in is progress on the minimum viable solution—because that’s the smallest part we could release and really get some value from in the outside world. So speak to that. Share with them the results from tests you’ve done with users or customers. They’ll be interested in learning that, too.

让组织内部的利益相关者看到您的进度和质量。

Keep your progress and quality visible to stakeholders inside your organization.

发布并继续评估

Release and Keep Evaluating

我在所有这一切结束时想象了最后一个规模。在这个规模上,我把我们一起审查过的部分堆积起来,与客户和用户一起测试,并让我公司的利益相关者看到。巧合的是,这个量表与我们在几步之前使用的量表非常相似——与用户和客户一起评估。与另一个秤一样,在配重上它表示“足够” ——但这次它意味着足以释放给那些客户和用户以产生我正在寻找的结果。当规模达到平衡时,将其发布给客户和用户。

I picture one last scale at the end of all this. On this scale I pile up the parts we’ve reviewed together, tested with customers and users, and made visible to stakeholders in my company. Coincidentally, this scale is very similar to the one that we used a couple of steps ago—evaluate with users and customers. As with this other scale, on the counterweight it says Enough—but this time it means enough to release to those customers and users to produce the outcome I’m looking for. When that scale balances, release it to customers and users.

没有标题的图片

但不要就此止步。你还有东西要学。如果您像第 3 章中的埃里克一样,学习是您的主要目标,那么您将需要使用指标来了解人们是否以及如何使用您的产品。您需要使用面对面的对话来了解他们为什么使用或不使用它。如果您预测人们会使用您的产品,并且他们和您的公司将从中受益,请不要只是假设。使用指标和对话来真正了解正在发生的事情。

But don’t stop there. You’ve still got something to learn. If you were like Eric in Chapter 3, learning was your primary goal, so you’ll need to use metrics to learn if and how people use your product. You’ll need to use face-to-face conversations to learn why they do or don’t use it. If you predicted that people would be using your product, and they and your company would be benefiting from it, don’t just assume that. Use metrics and conversations to really learn what’s happening.

使用指标和与用户面对面的时间来真正了解您的目标结果是否达到。

Use metrics and face time with users to really learn if your target outcomes were met.

如果这是一个项目,你就完成了——因为你交付了它。但你刚刚做了一些事情。这是一个产品。产品的生命交付之时就开始了。当你开始关注人们用你的产品做什么时,我保证你会找到改进它的机会。把它们写下来,并将它们反馈到这个模型的开头。

If this were a project, you’d be done—because you shipped it. But you just made something. It’s a product. And a product’s life starts when it’s delivered. When you start paying attention to what people are doing with your product, I promise you’ll find opportunities to improve it. Write those down, and feed them back into the beginning of this model.

这才是真正的生活循环——或者至少是故事中的生活。

That’s the real circle of life—or at least, the life of a story.

这是一个很大的突破。那么究竟应该由谁来进行所有这些岩石破碎工作呢?很高兴你提出这个问题,因为这就是下一章的内容。

And that’s a lot of rock breaking. So exactly who is supposed to do all that rock breaking? I’m glad you asked, because that’s what the next chapter is about.

第 12 章碎石机

Chapter 12. Rock Breakers

在常见的敏捷实践中有一个令人讨厌的错误假设:只有一个人负责编写故事并进行所有这些故事对话。在敏捷过程 Scrum 中,这个人被称为产品负责人。但是,有两个主要原因导致此逻辑不起作用,而且可能还有许多较小的原因。

There’s a nasty misassumption in common Agile practice: that there’s a single person responsible for writing stories and conducting all these story conversations. In the Agile process Scrum, that person is called the product owner. There are two big reasons, however, why this logic doesn’t work, and probably a lot of smaller reasons, too.

重要原因#1
Big reason #1
要将一个故事从模糊的想法转变为要构建的小而具体的事物,需要进行太多的对话。一个人不足以涵盖所有这些对话。而且,如果您将流程设置为必须有一个人在场,您很快就会发现这个人可能成为瓶颈,而且很可能会成为瓶颈。
There are too many conversations to have to move a story along its journey from vague idea to small, specific things to build. One person isn’t enough to cover all these conversations. And, if you set up your process so that one person has to be there, you’ll quickly see what a bottleneck that person can be, and likely will become.
重要原因#2
Big reason #2
一个人无法以达成最佳解决方案所需的专业知识和不同观点参与对话。需要具有不同技能的人通力合作才能真正找到最佳解决方案。
One person can’t come into the conversation with the expertise and diverse viewpoints it takes to arrive at a best solution. It takes the collaboration of people with different skills to really arrive at best solutions.

要求一个产品负责人编写所有故事并参与所有故事对话是行不通的。

Requiring a single product owner to write all of the stories and be present for all story conversations doesn’t work.

别误会我的意思。在我对良好产品开发的看法中,产品负责人是关键的领导者。他让产品和整个团队都专注于朝着同一个方向前进。

Don’t get me wrong here. In my vision of good product development, the product owner is a critical leader. He keeps the product and whole team focused on moving the same direction.

替代方案是由委员会设计的——一种非常糟糕的反模式,在这种模式中,每个人对我们所做的事情都有平等的发言权。在委员会中,当我们只有时间和资源做一件事时,我们就会妥协。我和我的前妻在选择餐厅时经常这样做。她想要海鲜,我想要墨西哥菜,我们会选择我们都不喜欢的东西。当一个委员会不受时间和资源的限制时,我们会全力以赴。您使用过这样的软件产品:产品的功能多得数不过来,而您最大的问题是找到功能或记住如何使用它。

The alternative is design by committee—a seriously bad anti-pattern where everyone gets an equal say in what we do. In a committee, when we only have time and resources to do one thing, we compromise. My ex-wife and I would often do this when choosing a restaurant. She wanted seafood, and I wanted Mexican food, and we’d settle on something neither of us liked. When a committee isn’t constrained by time and resources, we do it all. You’ve used software products like this: the product with more features than anyone can count, and where your biggest problem is finding the feature or remembering how to use it.

有效的产品负责人身边都是他们需要做出正确决策的人。他们结合了许多人的专业知识和意见。但是,最终,当资源受限或产品的成功受到威胁时,他们必须做出决定。总会有人对这个决定不满意。我的朋友 Leisa Reichelt 说很好:“社区设计不是委员会设计……设计从来都不是民主的。” [ 12 ]

Effective product owners surround themselves with the people they need to make good decisions. They incorporate the expertise and opinions of many. But, in the end, when resources are constrained or the success of the product is at stake, they must make decisions. And there’s always someone who’ll be unhappy with that decision. My friend Leisa Reichelt puts it well: “Design by community is not design by committee…design is never democratic.”[12]

有价值-可用-可行

Valuable-Usable-Feasible

Marty Cagan在他的著作《灵感:如何创造客户喜爱的产品》(SVPG 出版社)中描述了产品经理识别有价值、可用和可行的产品的责任。当我第一次读到这些话时,我在脑海中描绘了一个简单的维恩图,其中我们想要的解决方案是对我们公司和我们的客户有价值的东西的交集,可供用户使用,并且在我们的时间和工具的情况下是可行的有。

In his book Inspired: How to Create Products Customers Love (SVPG Press), Marty Cagan describes the responsibility of a product manager to identify a product that’s valuable, usable, and feasible. When I first read these words, I pictured in my head a simple Venn diagram where the solution we want is an intersection of what’s valuable to our company and our customers, usable by its users, and feasible to build given the time and the tools we have.

没有标题的图片

但这里可能不太明显的是,要真正确定处于最佳位置中心的解决方案,需要了解我们的业务、我们的客户、我们的用户和我们使用的技术的人员之间的协作——而不仅仅是了解这些事情,但对解决方案的成功负责。这些人实际上与利益相关者、客户和用户交谈;他们实际设计和测试用户界面;他们实际上设计和测试使产品工作的代码。

But what may not be dead obvious here is that, to really identify the solution in the center of that sweet spot will take collaboration between people who understand our business, our customers, our users, and the technology we use—and not just understand those things, but take responsibility for the success of the solution. These people actually speak with stakeholders, customers, and users; they actually design and test user interfaces; they actually design and test the code that makes the product work.

还记得敏捷开发中的误解,即单个产品所有者或产品经理决定构建什么吗?一个人拥有找到有价值的可用可行最佳点所需的业务、用户界面设计和工程技能,即使不是不可能,也是很少见的。这就是为什么最有效的组织使用小型、跨职能的探索团队来共同寻找正确的解决方案。正如我们在前一章中讨论的那样,将发现视为突破性的工作。我们所做的工作是将一个故事从一个模糊的大想法转变为我们可以构建的小而具体的东西。

Remember that misconception in Agile development where a single product owner or product manager decides what to build? It’s rare if not impossible for a single person to possess the business, user interface design, and engineering skills necessary to find that valuable-usable-feasible sweet spot. That’s why the most effective organizations use small, cross-functional discovery teams that work together to find that right solution. As we discussed in the preceding chapter, think of discovery as rock-breaking work. It’s the work we do to move a story from a big vague idea to something small and specific we can build.

由产品负责人领导的小型跨职能团队协调产品发现工作。

A small, cross-functional team led by a product owner orchestrates product discovery work.

团队的理想规模是 2 到 4 人——晚餐对话的规模,这样成员们可以快速建立共识。

The ideal size for the team is two to four people—dinner-conversation-sized so the members can quickly build shared understanding.

这个团队应该由对她的业务愿景和战略以及她的产品所服务的市场有深刻理解的产品所有者或产品经理领导。这个核心团队包括了解用户、乐于与他们合作以了解他们的工作方式并且可以绘制和创建简单的 UI 原型的人员。它还包括来自将构建产品的团队的高级工程师。此人需要了解系统的当前架构,并深入了解可用于解决棘手问题的新工程方法。这里真正的秘密在于,最具创新性的解决方案通常来自对业务问题和用户问题具有洞察力的工程师。

This team should be led by a product owner or product manager who has deep understanding of her business’s vision and strategy, and of the market her product serves. This core team includes someone who understands users, is comfortable working with them to learn about the way they work, and can sketch and create simple UI prototypes. It also includes a senior engineer from the team who’ll build the product. This person needs to understand the current architecture of the system and have insight into newer engineering approaches that could be used to solve tough problems. The real secret here is that the most innovative solutions often come from the engineer supplied with insight about the business problem and the users’ problems.

没有标题的图片

一个有凝聚力的发现团队是一个强大的、快速移动的专家组,他们可以快速发现问题并验证解决方案。我经常听到triad这个词来形容这个核心团队。在我最近访问位于悉尼的 Atlassian 时,您在第 8 章中遇到的 Sherif指着三个并排的座位。他解释说,“这就是三合会所在的地方。” 三合会周围的区域摆满了桌子和电脑,团队的其他成员就坐在那里。当发现团队中有两个人、四个人甚至更多人时,我会听到“三合一”一词,因为我们谈论的是三个问题——有价值、可用和可行——而不是三个机构。

A cohesive discovery team is a powerful, fast-moving group of experts who can find problems and validate solutions quickly. I often hear the term triad used to describe this core team. On my recent visit to Sydney-based Atlassian, Sherif, whom you met in Chapter 8, pointed to three seats close together. He explained, “This is where the triad sits.” The area around the triad was filled with desks and computers where the rest of the team sat. I hear the term triad used when there are two people, four people, or even more on the discovery team, since it’s the three concerns—valuable, usable, and feasible—we’re talking about, not three bodies.

通过包括用户体验、设计专业知识和技术专业知识的核心团队为产品所有者提供支持。

Support product owners with a core team that includes user experience, design expertise, and technical expertise.

探索团队需要很多其他人才能成功

A Discovery Team Needs Lots of Others to Succeed

有效的发现不仅可以协调与开发团队的协作,还可以协调业务利益相关者、主题专家、客户和最终用户的协作。这是一项艰巨的工作,除了每个团队成员带来的特定专业知识外,还需要一流的沟通和协调技巧。

An effective discovery coordinates collaboration with not only the development team, but also business stakeholders, subject matter experts, customers, and end users. It’s tough work that requires top-notch communication and facilitation skills, in addition to the specific expertise each team member brings in.

没有标题的图片

现在,这是真正的秘密。对于任何重要的产品,都需要一个团队来构建它。为了保持产品愿景清晰,确保团队构建的解决方案具有凝聚力,并帮助每个人朝着同一个方向前进,好的产品领导者至关重要。这些领导者中的佼佼者专注于帮助每个人掌握主人翁精神。在一个健康的故事驱动的环境中,你会看到很多故事对话一直在进行。他们中的许多人不需要那里的产品负责人。

Now, here’s the real secret. For a product of any significance, it’ll take a team to get it built. To keep the vision of the product clear, ensure the solution the team builds is cohesive, and help keep everyone moving in the same direction, a good product leader is critical. The best of these leaders focus on helping everyone take ownership. In a healthy story-driven environment, you’ll see lots of story conversations going on all the time. And many of them won’t need the product leader there.

三个朋友

The Three Amigos

¡三个朋友!是 1986 年一部平庸的西部喜剧的名字,由 Steve Martin、Chevy Chase 和 Martin Short 主演。这部电影与敏捷软件开发和故事有什么关系?在故事研讨会期间,有一个更具战术性的合作者三合会很有价值。我不确定最初是谁给他们起了“三个朋友”的绰号,但是它似乎卡住了。[ 13 ](我敢肯定,如果有更多人看过这部电影,那就不会了。)

¡Three Amigos! is the name of a mediocre 1986 western comedy starring Steve Martin, Chevy Chase, and Martin Short. What does this film have to do with Agile software development and stories? There’s a more tactical triad of collaborators that’s valuable during story workshops. And I’m not sure who originally gave them the moniker “the three amigos,” but it appears to have stuck.[13] (I’m sure if more people had seen the movie, it wouldn’t have.)

您可能还记得,故事研讨会是我对最后一次最佳对话的术语,在对话中我们具体决定要构建什么。这就是三个朋友进来的地方。

You might recall that story workshops is the term I give to that last best conversation where we decide specifically what to build. It’s here where the three amigos come in.

在最后一次最好的谈话中,我们确实需要考虑很多细节和实施的备选方案,因此我们需要团队中的一名开发人员来构建软件——理想情况下,是真正从事该软件工作的开发人员之一。

During this last best conversation, we really need to consider lots of details and alternatives for implementation, so we’ll need a developer from the team who’ll build the software—ideally, one of the developers who will actually work on it.

为了让这个小软件被认为已经完成,它需要进行测试,所以我们需要一个测试人员参与对话。测试人员——第一个朋友——通常会以批判的眼光看待讨论,比大多数人更早发现可能出错的地方。测试人员通常最擅长玩“What-About”游戏。

For this small piece of software to be considered done, it’ll need to be tested, so we’ll need a tester in the conversation. A tester—the first amigo—will often bring a critical eye into the discussion, spotting things that might go wrong sooner than most. The tester is often the best at playing the “What-About” game.

而且,当然,我们需要有人了解我们正在构建什么、它的用途以及我们为什么要构建它,因此我们需要该核心产品发现团队的一名成员。那个人就是第二个朋友。

And, of course, we’ll need someone who understands what we’re building, who it’s for, and why we’re building it, so we’ll need a member of that core product discovery team. That person is the second amigo.

在这个阶段,我们通常不会引入新的功能创意。我们可能已经在发现中这样做了。现在我们或多或少地致力于构建一些东西,所以明确了解该软件的外观和行为方式非常重要。因此,参与此对话的人通常是处理过这些细节的用户体验设计师或业务分析师。这是你的第三个朋友。

At this stage we’re often not introducing a new feature idea. We likely already did that back in discovery. Now we’ve more or less committed to build something, so it’s important to understand specifically how that software should look and behave. So often the person involved in this conversation is a user experience designer or business analyst who’s worked through those details. This is your third amigo.

没有标题的图片

该小组将研究细节并就故事的具体验收标准达成一致。通过这次对话,我们将对构建和测试软件所需的时间做出最佳估计。正是在这种对话中,我们经常决定将故事拆分为更小的、“大小合适”的开发故事——这些故事需要一到三天的时间来构建和测试。

This group will work through the details and agree on specific acceptance criteria for the story. It’s out of this conversation that we’ll have our best estimate of how long it will take to build and test the software. And it’s often in this conversation that we’ll make decisions to split the story into smaller, “right-sized” development stories—those stories that take one to three days to build and test.

当我们通过软件开发传递想法时,故事对话会不断发生。在每次谈话中,把有价值的、有用的、可行的都保留在讨论中。包括可以与这些事物交谈的人。通过让产品所有者对成功的、有凝聚力的产品负责来避免由委员会进行设计。

Story conversations happen continuously as we move ideas through software development. In every conversation, keep what’s valuable, what’s usable, and what’s feasible in the discussion. Include people who can speak to those things. Avoid design by committee by holding a product owner responsible for a successful, cohesive product.

作为生产者的产品负责人

Product Owner as Producer

如果您在更传统的 IT 环境中工作,产品负责人的概念可能看起来令人困惑。例如,如果您帮助银行构建关键系统,银行就会知道其真正的产品是向客户销售的银行服务。如果有人的正式头衔是“产品经理”,那么他的工作就是管理特定类型的银行账户或信贷产品。支持该服务产品的计算机系统只是拼图的一部分。通常,相同的 IT 基础架构支持许多不同的银行产品。可以理解的是,该银行并不将该基础设施视为一种产品,而且通常没有人拥有它。

If you work in a more traditional IT setting, the notion of a product owner may seem confusing. For example, if you help build critical systems for a bank, the bank knows its real products are the banking services it sells to its customers. If there is a person with the official title of “product manager,” it’ll be his job to look after a specific type of bank account or credit product. The computer systems that support that service offering are just a piece of the puzzle. And often that same IT infrastructure supports lots of different banking products. Understandably, the bank doesn’t see that infrastructure as a product, and there’s often no one who owns it.

在这些类型的组织中,业务分析师 (BA) 通常担任“需求收集”角色。他们将充当开发人员和业务利益相关者(如银行或保险产品的产品经理)之间的中介。当这些业务人员需要更改支持其产品的 IT 基础架构时,他们将与 BA 一起描述这些更改。这就是他们可能扮演客户角色的地方,因为 BA 扮演供应商角色,这就是反模式发挥作用的地方。

In these types of organizations, business analysts (BAs) are often placed in a “requirements gathering” role. They’ll act as an intermediary between the developers and the business stakeholders like the product manager of a banking or insurance product. When those businesspeople need changes to the IT infrastructure that supports their product, they’ll work with the BA to describe those changes. And here’s where they might take on the client role as the BA acts in a vendor role, and that’s where the anti-pattern kicks in.

在闲聊中,我的朋友大卫·哈斯曼 (David Hussman) 给了我一个更好的比喻来说明文学士与其业务利益相关者之间的关系——就像音乐制作人与乐队之间的关系一样。这对 David 来说是有道理的,他既是 Agile 大师,又是 1980 年代重金属乐队 Slave Raider 的前吉他手。他曾与制片人合作,自己也是制片人。在这种关系中,乐队带着激情进入音乐行业,希望有一些天赋,但他们不了解音乐行业或录制专辑的技巧。然而,生产者确实如此。制作人的工作就是帮助乐队录制出最成功的唱片。成功的制作人可以将才华横溢的天才变成具有商业可行性的唱片艺术家。

In casual conversation, my friend David Hussman gave me a better metaphor for the relationship the BA should have with his business stakeholders—the same relationship that a music producer has with a band. This makes sense coming from David, who’s both an Agile guru and ex-guitarist for the 1980s heavy metal band Slave Raider. He’s worked with producers, and been a producer himself. In that relationship the band comes to the music business with passion, and hopefully some talent, but they don’t know the music business or the mechanics of recording an album. The producer does, however. It’s the producer’s job to help that band make the most successful recording it can. Successful producers can turn raw talent into a polished, commercially viable recording artist.

作为 IT 环境中的业务分析师,这就是您的工作。了解您的业务利益相关者的愿景并帮助他们取得成功。你不能只是一个执行命令的人——你需要表现得更像一个医生。有时这意味着告诉您的利益相关者他们不想听到的事情。但是,如果您真诚地帮助他们取得成功,他们会看到并重视您的帮助。

As a business analyst in an IT context, that’s your job. Take the vision of your business stakeholders and help them make it a success. You can’t be just an order taker—you’ll need to behave more like a doctor. And sometimes this means telling your stakeholders things they don’t want to hear. But, if you’re sincere about helping them succeed, they’ll see it and value your help.

当作为其他利益相关者的想法的产品所有者时,扮演帮助他们成功的生产者的角色。

When acting as product owner for other stakeholders’ ideas, take on the role of a producer who helps them succeed.

一种潜在的反模式是让业务利益相关者承担产品所有权的角色。我说潜力是因为如果业务人员得到其他团队成员的大量帮助和支持,渴望学习如何完成产品负责人的工作,以及完成它所需的时间,它就可以发挥作用。产品所有权不是一项微不足道的责任,不应被视为可以在业余时间完成的事情。与其强迫商人从事另一份工作,我建议您为他们找一个制作人来帮助他们取得成功。

One potential anti-pattern is to make the business stakeholder take on the product ownership role. I say potential because it can work if the businessperson has lots of help and support from other team members, an aspiration to learn how to do the job of a product owner, and the time it’ll take to do it. Product ownership isn’t a trivial responsibility, and shouldn’t be treated as something that could be done in your spare time. Instead of forcing another job on businesspeople, I’d recommend you find them a producer to help them succeed.

这是复杂的

This Is Complicated

对于一个核心很简单的想法,整个故事变得非常混乱。如果有人告诉你软件开发——或任何产品开发,就此而言——很容易,那他们是在撒谎。

For an idea that at its core is simple, this whole story thing has gotten terribly messy. If anyone told you software development—or any product development, for that matter—was easy, they were lying.

故事同时包含很多东西。我们将使用这个词来指代卡片,指代我们构建的软件块,尤其是指我们必须就应该构建什么做出决定的那种对话。故事可以描述非常大的机会,或者本身对客户和用户来说不一定有意义的几乎微不足道的可交付成果。处理故事是一个持续的对话和讨论过程,将故事从大事分解为小事。通过所有这些对话,我们不仅关注我们可以构建什么,而且关注为谁构建以及为什么构建。故事地图只是帮助我们分解大事的方法之一,同时将对话的重点放在使用您产品的人以及他们成功的原因上。

Stories are many things at once. We’ll use the word to refer to the card, to the chunk of software we build, and especially to the kind of conversations we have to make decisions about what we should build. Stories can describe very large opportunities, or the almost insignificant deliverable pieces that by themselves aren’t necessarily meaningful to customers and users. Working with stories is a continuous process of conversation and discussion to break them down from big things to small things. And through all those conversations, we’re keeping not only what we could build in focus, but for whom, and why. Story mapping is just one of the ways to help us break big things down while keeping the focus of the conversation on the people using your product and what makes them successful.

如果这一切都开始变得有意义,那么你已经做出了重大的、必要的思维转变。这不是使用故事来记录需求的转变,而是转向更有效地与人合作,并共同专注于解决您创建的产品的实际问题。

If this is all starting to make sense, then you’ve made that big, necessary mindshift. It’s not a shift to use stories to document requirements, but a shift toward working with people more effectively, and together focusing on solving real problems with the products you create.

而且,我希望你会同意,这是一件美丽的事情。

And that, I hope you’ll agree, is a beautiful thing.




[ 12 ] Leisa Reichelt 最初在 2009 年的 IXDA 演讲中包含了这条宝贵的评论。在此处查看她后来的文章:http ://www.disambiguity.com/designbycommunity/ 。

[12] Leisa Reichelt originally included this gem of a comment in a 2009 IXDA talk. See her later essay here: http://www.disambiguity.com/designbycommunity/.

[ 13 ] Ryan Thomas Hewitt 在 Scrum Alliance 网站上发表的这篇文章解释了三个朋友式的故事研讨会:http ://bit.ly/Utg8er 。

[13] This article on the Scrum Alliance website by Ryan Thomas Hewitt explains a three amigos–style story workshop: http://bit.ly/Utg8er.

第 13 章 从机会开始

Chapter 13. Start with Opportunities

让我再次指出故事如何像岩石。就像一块石头,当你把它分成更小的部分时,你也可以称这些部分为“岩石”——只是更小的岩石。但总会有第一块石头。这是我们需要仔细研究的,以决定它是否值得分手。让我们称之为“零摇滚”。在我们的故事流中,我将称之为机会。

Let me point out again how stories are like rocks. And like a rock, when you break it into smaller parts, you can call those parts “rocks” too—just smaller rocks. But there’s always that first rock. That’s the one we’ll need to look closely at to decide if it’s worth breaking up or not. Let’s call it “rock zero.” And in our flow of stories, I’ll call that an opportunity.

我正在利用我们认为可以解决问题的想法的机会。我不仅仅是一个半满的人。只是将每个想法都视为我们需要包含在我们的产品中的东西是一个坏主意,因为您知道没有足够的时间和人员来构建所有这些东西。而且,即使您确实有时间和人员,您的客户也会不知所措。

I’m using opportunity for ideas that we believe will solve a problem. I’m not just a glass-half-full guy. It’s just that it’s a bad idea to consider every idea as something we need to include in our product, because you know that there isn’t enough time and people to build all that stuff. And, even if you did have the time and people, your customers would be overwhelmed.

就机会进行对话

Have Conversations About Opportunities

当我们想出点子时,这些点子往往非常宏大——但并非总是如此。用故事术语来说,你可以称它们为史诗,但我更愿意称它们为机遇不管你怎么称呼它们,它们仍然是故事,我们关于它们的第一次对话的目的是决定是继续使用它们,还是丢弃它们。对于这些机会中的每一个,我们可以讨论:

When we come up with ideas, these ideas are often pretty big—but not always. In story lingo, you could call them epics, but I prefer to call them opportunities. No matter what you call them, they’re still stories, and the goal of the first conversations we have about them is to decide whether to move forward with them, or trash them. For each one of these opportunities, we can discuss:

他们是为了谁
Who they’re for
在这个层面上,它是通常是不同的用户组、客户或目标市场。
At this level, it’s often different groups of users, customers, or a target market.
我们正在解决什么问题
What problems we’re solving
对于每种类型的用户,我们可以讨论我们正在为他们解决的问题。我们需要讨论他们如何通过使用手动工具、我们竞争对手的产品,或者更糟的是,我们的产品来解决他们今天的问题,这些产品今天给他们带来了痛苦。
For each type of user, we can talk about what problems we’re solving for them. We’ll need to talk about how they solve their problems today by using manual tools, our competitors’ products, or worse, our product that’s causing them pain today.
我们的想象
What we’re imagining
我们可能对产品或功能应该是什么有一些想法。我们应该讨论这些想法。
We may have some ideas about what the product or feature should be. We should discuss those ideas.
为什么
Why
现在是讨论为什么为这些用户构建软件对我们的组织有益的好时机。解决用户的问题通常是不够的。我们还需要考虑这项软件投资的最终回报,以及这项投资是否符合我们当前的业务战略。我并不是说我们需要计算投资回报率 (ROI),因为在这个阶段能够做到这一点的任何人都可能充满了故事以外的东西。只是笼统地讨论我们如何想象如果我们构建它,它将如何使我们的组织受益。
It’s a good time to discuss why it benefits our organization to build software for these users. Solving users’ problems usually isn’t enough. We also need to consider the ultimate return on this software investment and whether this investment is aligned with our current business strategy. I’m not saying we need to calculate return on investment (ROI), because anyone who can do that at this stage is likely full of something other than just stories. Just discuss in general terms how we imagine it’ll benefit our organization if we build it.
尺寸
Size
在这个级别,即使它们很大,我们也可以开始对开发时间进行一些直觉估计,尽管它不会很准确。最好的方法是查看机会并将其与您已经完成的事情进行比较:“这听起来就像我们在上一个版本中添加的其他功能一样。这花了几个星期,所以这可能需要大约相同的时间。” 为了帮助决定我们是否应该继续讨论这个想法,了解我们是否在谈论需要几天、几周或几个月才能构建的东西是很有价值的。
At this level, even when they’re big, we can start to give some gut estimate of development time, although it won’t be very accurate. It works best to look at the opportunity and compare it to something you’ve already done: “That sounds like it will be about like this other feature we put in the last release. That took a couple of weeks, so this may take about the same amount of time.” To help decide if we should proceed with discussion on this idea, it’s valuable to know if we’re talking about something that’ll take days, weeks, or months to build.

这些故事的全部堆栈就是我所说的机会积压我们还不确定是否应该建造它们,或者至少我们不应该建造它们。请记住,对于构建事物的想法总是比我们有时间的更多。找到与您组织的业务战略相一致的机会,并为客户和用户解决有吸引力的问题。进行足够的讨论以做出通过/不通过的决定。

The whole stack of these stories is what I call an opportunity backlog. We aren’t sure yet if we should build them, or at least we shouldn’t be. Remember, there are always more ideas for things to build than we’ll have time for. Find the opportunities aligned with your organization’s business strategy and that solve problems for customers and users that are compelling. Have enough discussions to make a go/no-go decision.

深入挖掘、丢弃它或思考它

Dig Deeper, Trash It, or Think About It

“开始”并不意味着“我们要建造这个东西”,它意味着我们将把机会推进到更深入的发现讨论中。在发现过程中,需要进行更多的讨论——可能与不在房间里的其他人进行讨论。如果这是一项新功能或全新产品,则需要更深入地了解客户和用户以及他们如何解决当今的问题。理想情况下,我们会直接与他们交谈。这将需要探索和制作不同解决方案的原型。根据您和您的团队所学到的知识,需要进行大量更深入的讨论,才能决定您具体需要构建哪些内容才能对客户、用户和您的组织有价值。而且,在所有这些工作之后,您仍然可能决定扼杀这个想法。

“Go” doesn’t mean “We’re gonna build this thing,” it means we’ll move the opportunity forward into deeper discovery discussion. During discovery, it’ll take a lot more discussion—probably with others not in the room. If this is a new feature or an entirely new product, it’ll take diving a lot deeper into customers and users and how they solve their problems today. Ideally, we’ll talk to them directly. It’ll take exploring and prototyping different solutions. It’ll take lots of deeper discussions in light of what you and your team learn to make a decision about what specifically you’ll need to build to be valuable to customers, users, and your organization. And, after all that work, you still might decide to kill the idea.

“不去”是机会讨论的一个很好的结果。请记住,要建造的东西总是比时间多。如果根据您的讨论,这个机会看起来没有希望,现在就把它扔掉。让支持该想法的人参与讨论可能是个好主意,希望他们能得出相同的结论。

“No-go” is a great result of an opportunity discussion. Remember, there’s always more to build than there is time. If the opportunity doesn’t look promising based on your discussion, trash it now. It may be a good idea to involve the people who championed the idea in the discussion so hopefully they come to the same conclusion.

您的小组可能没有足够的信息来做出继续或不继续的决定。如果是这种情况,请列出您需要学习的内容,然后一起开始工作以获取所需的信息。

Your group may not have enough information to make either a go or a no-go decision. If that’s the case, make a list of what you need to learn, and together get to work getting the information you need.

如果您仍然不能做出继续或不继续的决定,您可以随时将其放回机会待办列表中,稍后再讨论。这就是所谓的拖延症,我经常这样做。

If you still can’t make a go or no-go decision, you can always put it back into the opportunity backlog to discuss later. That’s called procrastination, and I do it a lot.

没有标题的图片

机会不应该是委婉的说法

Opportunity Shouldn’t Be a Euphemism

我知道你的公司可能不会利用机会。事实上,如果你的公司和我合作过的公司一样,你就有了一张路线图,上面写满了你应该构建的东西。您甚至可以将它们视为您的“要求”。对任何这些东西做出不去的决定可能不是你的决定。事实是,我们真的不应该将所有这些聪明的想法都变成软件,无论拥有聪明想法的人的职位是什么。

I know your company probably doesn’t use opportunities. In fact, if your company is anything like those I’ve worked with, you’ve got a roadmap filled with stuff you’re supposed to build. You may even think of them as your “requirements.” Making a no-go decision on any of that stuff may not be your call. The truth is, we really shouldn’t turn all those clever ideas into software, no matter the job title of the person with the clever idea.

使用这第一次重大故事对话来构建您和您的团队可能要从事的工作。即使对通过/不通过问题的答案可能是“开始”,但请确保您在结束对话时就您正在解决的问题、为谁以及您的组织如何从构建软件中获益达成共识。

Use this first big story conversation to frame the work you and your team may be getting into. Even though the answer to the go/no-go question may be “Go,” make sure you leave the conversation with shared understanding about the problems you’re solving, for whom, and how your organization benefits from building software.

如果您或您团队中的任何人都不能决定继续利用这个机会,那么请确保您将可以做出该决定的人包括在对话中。如果他们不可用,无论如何都要进行对话,并对谁、什么以及为什么做出假设。然后与决策者分享这些假设。我向你保证,如果你做错了,他们会纠正你。讨论这些更正将开始正确的对话。

If it’s not your decision, or anyone on your team’s decision, to go ahead with this opportunity, then make sure you include those in the conversation who can make that decision. If they’re not available, have the conversation anyway, and make assumptions about who, what, and why. Then share those assumptions with decision makers. I promise you that they’ll correct you if you’ve got it wrong. Discussing those corrections will start the right conversation.

故事映射和机会

Story Mapping and Opportunities

尽管我喜欢故事地图,但我不会使用地图来管理机会。这些机会通常是更大的块。关于这些大石头的讨论通常会朝着我们需要的细节推进,以便我们决定将它们带入更深层次的发现。

As much as I like story maps, I wouldn’t use a map to manage opportunities. Those opportunities are usually bigger chunks. And discussion about these big rocks usually drives toward the details we’ll need in order to decide about moving them into deeper discovery.

但故事地图擅长的一件事是为您提供了一种真正有效的方式,让您退后一步,查看您现在拥有的产品的全局。使用您今天为您的产品创建的地图来寻找机会,或者考虑您今天的产品背景下已经拥有的机会。

But one thing that story maps are great at is giving you a really effective way to step back and look at the big picture for the product you have now. Use a map you create for your product today to find opportunities, or to consider the opportunities you already have in the context of your product today.

尝试为现有产品构建一个简单的、非常高级的地图。这是一个“现在”地图,类似于您在第 5 章中构建的关于开始您的早晨的地图。(你确实建造了它,不是吗?)这些类型的地图已经以各种形式出现了一段时间。它们通常被称为旅程地图要为您当前的产品体验制作一张地图,只需绘制用户在他们从事的主要活动中所经历的流程。使用此地图为您的机会提供背景信息。为此,将每个机会添加到地图主体中。使用不同颜色的便利贴或索引卡清楚地标出它们。您可能看到的是机会“热点”——用户流中的想法密度较高且用户可能会感到痛苦的地方。

Try building a simple, very high-level map of your existing product. This is a “now” map similar to the one you built in Chapter 5 about starting your morning. (You did build it, didn’t you?) These types of maps have been around in various forms for a while. They’re often called journey maps. To make one for your current product’s experience, just map the flow users take through the major activities they engage in. Use this map to give context to your opportunities. To do this, add each opportunity into the body of the map. Use a different color of sticky note or index card to clearly call them out. What you might see are opportunity “hot spots”—places in your users’ flow where there’s a higher density of ideas and likely pain from your users.

查看参与每项活动的用户,以及该活动的频率。影响关键用户参与的高频活动的机会很可能是您应该关注的机会——宜早不宜迟。

Look at the users engaged in each activity, and the frequency of that activity. Opportunities that affect high-frequency activities engaged in by critical users are likely opportunities you should be focusing on—sooner rather than later.

您可以使用同一张地图为用户今天抱怨的事情添加卡片。为了平衡事物,看看他们今天喜欢的产品部分,并添加这些乐趣。如果您发现用户有很多痛苦的地方,但您还没有发现任何机会,您可能应该这样做。

You can use this same map to add in cards for the things users complain about today. To balance things, look at the parts of the product that they love today, and add in those joys. If you find places where there’s lots of pain for users, but you haven’t yet identified any opportunities, you probably should.

没有标题的图片

挑剔

Be Picky

如果你同意承担一切,你就不是在帮助任何人。积极地丢弃那些对创造你所希望的结果没有多大希望的机会。与业务利益相关者合作来做到这一点,以便他们可以帮助做出这些决定。

You’re not helping anyone if you agree to take on everything. Aggressively trash opportunities that don’t offer much hope of creating the outcomes you hope for. Work with business stakeholders to do this so they can help make those decisions.

如果您做出了前进的决定,那么就该卷起袖子开始工作了。这就是下一章的内容。

If you’ve made a go-forward decision, it’s time to roll up your sleeves and get to work. And that’s what the next chapter is about.

第 14 章使用发现建立共同理解

Chapter 14. Using Discovery to Build Shared Understanding

当我看到描述敏捷开发的简单模型时,它们通常从左侧的大列表开始——产品积压现在,如果我不知道有些人认为这很容易,我会认为这很有趣。从一个机会中获得一个好的可操作的产品积压将需要大量的努力;它不会简单地为你实现。这绝对不是捕获人们想要构建的东西列表的结果。这是一个深思熟虑的发现过程,最初侧重于更多地了解谁、什么和为什么。

When I see simple models that describe Agile development, they often start on the left side with a big list—the product backlog. Now, I’d consider that funny if I didn’t know that some people consider it that easy. Getting a good actionable product backlog out of an opportunity is going to take a lot of hard work; it won’t simply materialize for you. And it definitely isn’t the result of capturing a list of things people want built. It’s a deliberate process of discovery that initially focuses on learning a lot more about who, what, and why.

发现与构建软件无关

Discovery Isn’t About Building Software

发现工作与构建可交付软件无关。这是关于学习。这是关于加深对我们可以建造什么的理解。这是关于提出和回答以下问题:

Discovery work isn’t about building shippable software. It’s about learning. It’s about building a deeper understanding of what we could build. It’s about asking and answering questions like:

  • 我们真正解决的是 什么问题?
  • What problems are we really solving?
  • 哪些解决方案对我们的组织以及购买或采用该产品的客户 有价值?
  • What solutions could be valuable to our organization and to customers buying or adopting the product?
  • 可用的解决方案 是什么样的?
  • What does a usable solution look like?
  • 考虑到我们拥有的时间和工具,建造 什么是可行的?
  • What’s feasible to build given the time and tools that we have?

它询问并开始回答所有这些关于开始您第一轮突破的机会的问题。您讨论的有关产品或功能的所有详细信息都将成为较小故事的标题。这些小故事中的每一个都可能导致更深入的讨论和更小的故事。

It’s asking and starting to answer all these questions about an opportunity that starts your first round of rock breaking. All the details about the product or feature you discuss become the titles of smaller stories. And each of those smaller stories can result in even deeper discussions, and still smaller stories.

没有标题的图片

所有这些发现讨论不仅会产生更多故事。请记住,故事讨论涉及创建许多其他简单模型来代表我们所理解的内容。我们将需要这些其他简单的模型来建立共同的理解。

All these discovery discussions don’t just result in more stories. Remember that story discussions involve creating lots of other simple models that represent what we understand. We’ll need these other simple models to build shared understanding.

如果你在理解一个大的、模棱两可的机会时创造的唯一东西是较小的故事,那么你可能做错了。

If the only thing you create while making sense of a big, ambiguous opportunity is smaller stories, then you’re probably doing it wrong.

发现的四个基本步骤

Four Essential Steps to Discovery

如果我有一个大点子,或者是一个需要澄清的小点子,如果我们有一个值得构建的解决方案,我将按照讨论的这一进程从大的想法转移到我需要最好地理解的细节:

If I’ve got a big idea, or even a small one that needs some clarity, I follow this progression of discussions to move from the big idea to the details I’ll need to best understand if we’ve got a solution worth building:

  1. 从业务角度 构建想法。
  2. Frame the idea from a business perspective.
  3. 了解客户和用户以及您如何帮助他们。
  4. Understand customers and users and how you’re helping them.
  5. 设想您的解决方案。
  6. Envision your solution.
  7. 最小化并计划确定最小的可行解决方案以及您将如何构建它。
  8. Minimize and plan to identify the smallest viable solution and how you’ll build it.

1. 构建想法

1. Frame the Idea

如果你真的使用机会积压,并且真的有一次机会讨论来决定开始发现,那么你就完成了大部分工作。使用框架讨论来启动有针对性的发现。让将一起工作的人参与进来,以更好地理解这个机会。

If you really use an opportunity backlog, and really had an opportunity discussion to make your decision to begin discovery, then you’re most of the way there. Use framing discussions to kick off focused discovery. Involve the people who’ll work together to better understand this opportunity.

使用框架讨论为您正在做的工作设定界限。如果您清楚为什么要构建某物以及它为谁构建,您和您的团队将能够更好地停止讨论无法解决您所关注的问题或不适合用户的解决方案你瞄准了。

Use framing discussions to set bounds for the work you’re doing. If you’re clear on why you’re building something and who it’s for, you and your team will be better able to stop discussions about solutions that don’t solve the problem you’re focusing on, or aren’t for the users you’ve targeted.

2.了解客户和用户

2. Understand Customers and Users

使用关于客户的讨论和用户,以更深入地了解您的产品或功能所针对的人群,以及他们如何从中受益。让那些对用户有深刻理解的人,以及其他需要了解的人参与进来。

Use discussions about customers and users to gain more insight into the people your product or features are for, and how they benefit them. Involve those who have deep user understanding, and others who need to get it.

绘制简单的人物角色

Sketch simple personas

我喜欢与小型发现团队一起创建简单的角色草图建立对我的用户的共同理解。角色是您的目标用户的一个例子,它是根据事实,有时是您对用户的假设组合而成的。建立人物角色有助于我们通过用户的眼睛来看待软件。角色是方便的工具。

I like creating simple persona sketches with a small discovery team to build shared understanding of my users. A persona is an example of your target user assembled from the facts and sometimes the assumptions you have about your users. Building personas helps us look at the software through the eyes of our users. Personas are handy tools.

没有标题的图片

我与 Mano a Mano 的一个团队建立了这个简单的角色,这是一个非营利组织,通过从修建道路到支持教育和医疗保健等方方面面来帮助玻利维亚人民。我们今天的讨论是关于小型、精通互联网的捐助者——这类人可能没有很多钱,但希望他们必须捐赠的东西得到明智的使用。我们希望像 Chuck 这样的人能够在 Web 上找到 Mano a Mano,或者通过 Twitter 或 Facebook 听说它。

I built this simple persona with a group at Mano a Mano, a nonprofit group that helps people in Bolivia by doing everything from building roads to supporting education and healthcare. Our discussion this day was about small, Internet-savvy donors—the sort of people who may not have a huge amount of money, but want what they do have to give to be used wisely. We’d expect people like Chuck to find Mano a Mano on the Web or hear about it via Twitter or Facebook.

我们使用活动挂图纸作为一个小组一起创建了这个角色。这是一项快速、有趣的活动,有很多人大声喊叫并提供信息。

We created this persona together as a group using flipchart paper. It’s a fast, fun activity with lots of people shouting and contributing information.

现在,如果你是一位经验丰富的 UX 设计师,之前创建过角色,你现在可能会感到有点反胃。对于您阅读的其余部分,良好的角色是根据通过扎实的研究收集的良好数据构建的。担心这一点的用户体验人员可能会对团队成员大喊大叫并在活动挂图纸上涂鸦感到紧张。听起来不严谨。所以不要只是大声说出你的猜测。讨论你所知道的和你观察到的。讲故事。让对用户有第一手经验的人参与讨论。如果你做了很多研究,把它带入与你的讨论中。确定与您正在构建的机会最相关的细节并将其放入角色中。过滤掉噪音。完成后,就其中有多少只是猜测进行诚实的讨论。

Now, if you’re an experienced UX designer who’s created personas before, you may be feeling a little sick to your stomach right now. For the rest of you reading, good personas are built from good data gathered through solid research. UX people concerned about that might be nervous about team members just shouting stuff out and scribbling it on flipchart paper. It doesn’t sound rigorous. So don’t just shout your guesses. Discuss what you know and what you’ve observed. Tell stories. Involve people in the discussion who have firsthand experience with users. If you’ve done lots of research, bring it into the discussion with you. Identify the details most relevant to the opportunity you’re building and put those into the persona. Filter out the noise. When you’re done, have an honest discussion about how much of this is just a guess.

“我们已经创建了角色。它们是我们贴在墙上的精美文件。” 我听到很多。但要对自己诚实。大多数人没有读过它们,是吗?读过这些文章的人中有一半只是为了取笑他们。也许我很愤世嫉俗,但我看到了很多。

“We already have personas created. They’re beautiful documents we’ve posted on the wall.” I hear that a lot. But be honest with yourself. Most people haven’t read them, have they? And half of the people who did read them did so just to poke fun at them. Maybe I’m being cynical, but I see that a lot.

共同构建角色,协作。这样做是为了与团队就谁将构建产品建立共识。这样做是为了真正考虑人物角色最相关的方面。

Build personas together, collaboratively. Do this to build shared understanding with the team about who’ll build the product. Do this to really consider the most relevant aspects of the persona.

一起构建轻量级角色,以在团队内建立共同的理解和同理心。

Build lightweight personas together to build shared understanding and empathy within the team.

我为可能使用我们正在讨论的功能的每种类型的用户创建简单的角色。如果我行动迅速,我可能只列出使用该软件的不同类型的用户或角色,并记下有关它们的一些细节。还记得第 1 章中的加里吗?紧挨着 Gary 的一堆卡片中的一张就是这样的——用户列表和一些关于他们的相关信息。

I create simple personas for each type of user who might use the feature we’re discussing. If I’m moving fast, I may just list different types of users or roles using the software, and note a few details about them. Remember Gary in Chapter 1? One of the piles of cards right next to Gary was exactly that—a list of users and a few bullets of relevant information about them.

创建组织概况或 orgzonas

Create organizational profiles or orgzonas

如果您正在构建组织可能购买的产品(例如会计产品),请花时间列出不同类型的组织并记录有关它们的一些详细信息。这些是你的客户——手头有现金的人,他们需要从你的产品中获得一些价值。具有一些支持详细信息的组织类型通常称为组织概况。我的朋友 Lane Halley 首先向我介绍了如何创建示例组织配置文件,就像创建角色一样。为了好玩,她称它们为orgzonas

If you’re building a product that organizations might buy—for example, an accounting product—take the time to list different types of organizations and record some details about them. These are your customers—the people with cash in hand who need to get some value from your product. An organization type with some supporting details is often called an organizational profile. My friend Lane Halley first introduced me to creating example organizational profiles much like you’d create a persona. For fun, she called them orgzonas.

映射用户今天的工作方式

Map how users work today

您可以更深入地了解用户在没有您的产品或使用当前产品时的工作方式。如果你在第 5 章中一起玩,你就构建了一个关于你今天做事方式的故事地图。按照您的用户今天的工作方式执行此操作将帮助您的发现团队真正了解他们正在解决的问题。

You can go one step deeper and map the way your users work today without your product, or with your current product. If you were playing along in Chapter 5, you built a story map about the way you do things today. Doing this for the way your users work today will help your discovery team really understand the problems they’re solving.

没有标题的图片

这些来自 Caplin Group 的 Duncan Brown 的照片展示了他们称之为叙事旅程地图的东西。这是一张地图,讲述了我在本书开始时使用的“现在和以后”模型的“现在”方面的故事。它没有描述我们的伟大解决方案;它描述了当今人们实现目标的方式——错误和所有。

These photos from Duncan Brown of the Caplin Group show something they call a narrative journey map. It’s a map that tells a story about the “now” side of the “now-and-later” model I started this book with. It doesn’t describe our great solution; it describes the way people reach their goals today—faults and all.

地图的主体包含事实、观察、痛苦和欢乐。当您映射您现在理解的内容时,您会看到“热点”——流程中存在很多问题的区域。您还会发现奖励——在一组步骤结束时让您的用户的努力值得的乐趣。您可以通过消除痛苦或放大快乐来构建有价值的产品。使用此地图作为集思广益解决方案的跳板,或验证您想到的解决方案是否确实解决了问题。

The body of the map contains facts, observations, pains, and joys. When you map what you understand now, you’ll see “hot spots”—areas in the flow where there are lots of problems. You’ll also find rewards—the joys at the end of a set of steps that make your users’ efforts worthwhile. You can build valuable products by taking away pains, or magnifying joys. Use this map as a springboard for brainstorming solutions, or for validating that the solution you have in mind really does solve problems.

3.设想你的解决方案

3. Envision Your Solution

到目前为止,您已经清楚地了解为什么要从业务角度构建它;您已经更深入地了解用户和客户,因此您了解他们的世界现在是什么样子。现在是想象未来的时候了——设想解决方案以及您的目标客户和用户将如何使用它。

By now you’ve framed to be clear on why you’re building this from a business perspective; you’ve dived deeper into users and customers so you know what their world looks like now. It’s time to imagine the future—to envision the solution and how your target customers and users will make use of it.

映射您的解决方案

Map your solution

这是故事地图的亮点,至少对我而言。我使用故事地图来想象我的用户使用我们正在构建的解决方案的生活。Gary 和 Globo.com 团队在前两章中都构建了这样的地图。正如我们在开头章节中讨论的那样,人们在你讲述的故事中采取的步骤形成了从左到右的流程。请记住第 4 章,这些是用户任务——从左到右阅读时可以讲述故事的简短动词短语。更细粒度的任务和其他细节在每个步骤下垂直堆叠。如果故事很长,则提取活动组以创建三层地图。

This is where story maps shine, at least for me. I use the story map to imagine the life of my users with the solution we’re building in place. Both Gary and the Globo.com team in the first two chapters built maps like this. As we discussed in the opening chapters, the steps people take in the story you tell form the left-to-right flow. Remember from Chapter 4 that those are user tasks—short verb phrases that, when read from left to right, tell the story. The finer-grained tasks and other details stack up vertically under each step. If it’s a long story, distill groups of activities to create a three-level map.

文字与图片

Words and pictures

您是否遇到过向开发人员描述产品创意的情况,当他说:“哦,这很简单。建造起来应该不会花很长时间。” 但是,当您真正着手并开始构建它时,您会意识到开发人员想象的东西比您想象的要简单得多。例如,您可能已经描述了一个在线销售您的东西的网站。您可能一直在想象像 eBay 或 Amazon Marketplace 这样的东西。但开发人员正在想象更像 Craigslist 的东西,这就是为什么你对这个估计感到满意。我在过去十年中了解到,仅靠文字是不够的。

Have you ever been in a situation where you describe a product idea to a developer, and are pleasantly surprised when he says, “Oh, that’s simple. It shouldn’t take long to build.” But, then when you really get going on it and start building it, you realize the developer was imagining something far simpler than you were. For example, you might have described a site to sell your stuff online. You might have been imagining something like eBay or Amazon Marketplace. But the developer was imagining something more like Craigslist, and that’s why you were pleased with the estimate. I’ve learned over the last decade that words alone just aren’t enough.

可视化您的用户界面以建立对解决方案的共同理解。

Visualize your user interface to build shared understanding of the solution.

如果你的团队中有 UX 设计师,现在是他们开始绘制草图的好时机。绘制单个屏幕并按照它们出现的顺序将它们张贴在地图上方。你最终会得到一个看起来像故事板的东西。

If you’ve got UX designers on your team, now’s a good time for them to start sketching. Sketch individual screens and post them above the map in the order they appear. You’ll end up with something that looks like a storyboard.

设想涉及整个团队的用户体验的一种方法是设计工作室方法。设计工作室是一种快速、简单且协作的方式,可以让一大群人参与深思熟虑的构思,这是一个华而不实的词,可以提出很多可能的想法。您很快就会了解到,没有一个人拥有最好的想法。相反,最好的想法通常是几个人的想法以及更多讨论的结合。设计工作室(和简单的想法,就此而言)与包括我在内的大多数人经常做的事情相反:接受第一个看起来可行的想法。我第一次看到Jeff White 和 Jim Unger描述的 Design Studio 时想知道为什么我没有一直这样做。我已经完成了这些涉及开发团队、利益相关者,甚至客户和最终用户的工作。

One approach to envisioning the user experience that involves the whole team is a Design Studio approach. A Design Studio is a fast, simple, and collaborative way to involve a large group in deliberate ideation, which is a flashy word for coming up with lots of possible ideas. What you’ll quickly learn is that no single person has the best ideas. Rather, the best ideas are often a combination of several people’s ideas along with more discussion to build on them. A Design Studio (and simple ideation, for that matter) is the opposite of what most folks, including me, often do: go with the first idea that seems like it’ll work. I first saw Design Studio described by Jeff White and Jim Unger and wondered why I hadn’t always been doing it. I’ve done these involving development teams, stakeholders, and even customers and end users.

无论您使用什么方法,结合想法,完善它们,并对软件的外观达成共识。

Whatever approach you use, combine ideas, refine them, and come to a shared understanding of what the software could look like.

这里发生的一件令人不安的事情是可视化您的解决方案将帮助您捕捉到您在地图中错过的东西。您会发现您可能需要添加、更改或重新组织地图以支持您的可视化内容。别担心:这是件好事。

An uncomfortable thing that happens here is that visualizing your solution will help you catch things you’ve missed in the map. You’ll find you may need to add, change, or reorganize the map to support what you’ve visualized. Don’t worry: that’s a good thing.

验证完整性

Validate completeness

我们的头脑擅长的事情之一就是填写细节。例如,当我们看到漫画的两帧画面时,我们的大脑会填充其间发生的事情。对于漫画书、小说和电影来说,这是一个很酷的技巧。但是,在思考软件的功能时,我们通常会想象有趣的功能,而忽略其间发生的必要内容。过度扩展电影隐喻,有点像只谈论汽车追逐和枪战,而忽略了解释为什么所有这些动作发生的故事。

One of the things our heads are good at is filling in details. For example, when we see two frames of a comic strip, our brains fill in what happened in between. This is a cool trick for comic books, novels, and movies. But, when thinking through what software does, we’ll often imagine the interesting features while neglecting the necessary stuff that happens in between. Overextending the movie metaphor, it’s sort of like talking only about the car chases and gunfights, and leaving out the story that explains why all that action took place.

使用地图讲述用户故事的全部内容可以帮助您记住谈论中间的那些关键细节。您通常会发现,您所考虑的非常酷的功能需要在故事的早期由用户进行一些设置,并导致在故事的后期对报告和通知进行一些更改。您的新功能创意甚至可能会对其他人产生影响。例如,管理员可能需要管理安全问题,或者经理可能希望监督其员工如何使用该功能。

Telling the full breadth of your users’ stories using a map helps you remember to talk about those critical details in between. You’ll usually see that the really cool feature you were thinking of needed some setting up by the user early in the story, and resulted in some changes to reports and notifications later in the story. There may even be consequences for others of your new feature idea. For example, administrators may need to manage security concerns, or managers may like oversight on how the feature is being used by their staff.

验证工程问题

Validate engineering concerns

回到电影制作的比喻,如果你打算继续制作这部电影,你需要开始考虑如何以及在哪里拍摄它。您需要考虑所需的特殊效果种类。在某些时候,您需要比故事更深入,并考虑制作电影的技术细节。

Back to the filmmaking metaphor, if you are going to move on to make this movie, you’ll need to start thinking about how and where you’ll film it. You’ll need to consider the kinds of special effects you’ll need. At some point you’ll need to go deeper than the story and consider the technical details of making your movie.

软件的故事地图有助于进行与制作电影时相同的讨论。在取得进展之前,与工程师和架构师讨论您的解决方案图。纵观大局有助于他们思考更大的工程限制,这些限制可能会导致解决方案存在无可救药的缺陷。他们可以提前警告您,您的解决方案可能听起来很酷,但考虑到您当前的体系结构和时间预算,构建它是不可行的。他们通常可以建议替代方法来为您的用户提供同等体验,但构建起来更具成本效益。

A story map of your software is helpful for the same kind of discussion you’d have making a movie. Discuss your solution map with engineers and architects before getting too far along. Seeing the big picture helps them think through bigger engineering constraints that could result in hopelessly flawed solutions. They can give you early warning that your solution may sound cool, but it’s not feasible to build given your current architecture and time budget. They can often suggest alternative ways of doing things that’ll give your users an equivalent experience, but be more cost effective to build.

没有标题的图片

这些大型保险公司的工程师已经在这张地图前讨论了很长时间。在他们的谈话过程中,他们在这张关于他们产品的大地图中发现了一个障碍。他们产品中的业务规则引擎需要改变。看到大局帮助他们形象化并直接面对复杂性。他们将利用这些知识来讨论他们可以计划及早采取哪些措施来帮助降低风险。

These engineers for a large insurance company have been talking in front of this map for a long time. During the course of their conversation, they’ve found a snag in this big map about their product. The business rules engine in their product needs to change. Seeing the big picture helped them visualize and directly confront the complexity. They’ll use that knowledge to talk about what they can plan to do early to help mitigate risks.

播放“关于什么”

Play “What-About”

您已经从用户的角度设想了解决方案,并将用户体验形象化。花点时间讨论一下用户界面下面发生了什么。谈论严格的业务规则、复杂的数据验证以及您需要连接的讨厌的后端系统或服务。将故事添加到命名这些部分的地图中。或者确保你对你的故事做笔记。

You’ve imagined the solution from a user’s perspective, and visualized the user experience. Take some time to discuss what’s going on underneath the user interface. Talk about tough business rules, complex data validation, and nasty backend systems or services you’ll need to connect with. Add stories into the map that name these parts. Or make sure you make notes on the stories you have.

现在也是与许多其他人一起回顾你所拥有的东西的好时机。分享你和你的小组的想法。我保证你会遇到问很多问题的人,这些问题以“关于……怎么样”开头。我喜欢这些人,尽管当他们就在我面前时并不总是这样。但我喜欢他们帮助我在我后来偶然发现困难的事情之前思考困难的事情,那时学习起来会更加痛苦。

It’s a good time to review what you’ve got with lots of other people as well. Share what you and your group have come up with. I promise you’ll get people who ask lots of questions that start with “What about…” I love these people, although not always when they’re right in front of me. But I love that they’re helping me think of the tough stuff before I stumble on it later, when it’ll be even more painful to learn.

电影隐喻在这里对我来说真的很管用。如果我要拍一部电影,我会想要一个剧本和一个故事板——帮助我想象这部电影的关键场景的草图。如果我正在投资一部电影,我至少需要看到它才能清楚地了解编剧和导演的设想。如果我现在喜欢这部电影,我将需要更多地了解它的成本以及制作的可行性。

The movie metaphor really works for me here. If I were going to make a movie, I’d want a screenplay and a storyboard—the sketches of key scenes that help me imagine the movie. If I were investing in a movie, I’d need to see at least that to get a clear picture of what the writers and directors were envisioning. If I liked the movie at this point, I’m going to need to learn a bit more about how much it costs, and how feasible it is to produce.

我希望他们能使用这些草图来更深入地思考这部电影。我想知道他们考虑过我们需要拍摄多少个地点以及它们的外观。我想知道他们考虑过我们需要什么样的布景、道具和特效。作为重要的好莱坞投资者,我需要剧本、故事板和许多其他细节来支持粗略的计划和估算。我们需要这个,这样我们才能为制作这部电影设定预算和时间表。

I’d hope they’d use those sketches to think more deeply about the movie. I’d want to know that they’d considered how many locations we’d need to film in and what they looked like. I’d want to know that they’d considered what kinds of sets, props, and special effects we’d need. As the important Hollywood investor, I’d need the screenplay, the storyboard, and lots of other details that supported a rough plan and an estimate. We’d need this so we could set a budget and a timeline for making the movie.

这是您开始构建解决方案之前需要的东西。

This is the sort of stuff you need before you start building your solution.

还不庆祝

Don’t celebrate yet

通过发现流程中的这一步,您应该已经开始将您的解决方案的各个部分描述为单独的故事。每件作品都是重大机遇的一部分。如果您像我一样,已经使用故事地图来组织所有部分。如果你比我聪明,你会发明一种更好的方法来组织所有的部分——如果是这样的话,你应该马上联系我。如果你有点昏暗,你就会有一大堆。甚至更糟的是,有人可能编写了一份冗长的需求文档,混淆了您所学的一切。请不要那样做。

By this step in the discovery flow, you should have begun to describe your solution’s parts as individual stories. Each piece is a part of the big opportunity. If you’re like me, you’ve used a story map to organize all the parts. If you’re smarter than me, you’ll have invented an even better way to organize all the parts—and if that’s the case, you should get in touch right away. If you’re a little dim, you’ll just have a big pile. Or even worse, someone may have written a big long requirements document that obfuscates all you’ve learned. Please don’t do that.

无论你在这里结束了什么,你都处于许多人庆祝的时刻,因为他们已经“完成了要求”。不要成为那些人。您还有最后也是最重要的一步要做。

Whatever you end up with here, you’re at the point where lots of people celebrate because they’ve “finished the requirements.” Don’t be those people. You’ve got a last and most important step to do.

4. 最小化和计划

4. Minimize and Plan

您已经设想了一个带有文字和图片的解决方案,在这一点上,您的团队可能会感到非常自豪。但发现的一大问题当我们齐心协力找出一个绝妙的解决方案时,就会发生这种情况,其中包含我们都喜欢的许多花里胡哨的东西。

You’ve envisioned a solution with words and pictures, at this point, your team may be feeling pretty proud. But one of the big problems with discovery happens when we all work together to identify a fabulous solution with lots of bells and whistles that we all love.

我知道你在想什么。为什么那会是个问题?

I know what you’re thinking. Why would that be a problem?

当我们专注于让每个人都开心,而同时未能专注于小的、具体的目标结果时,问题通常就会出现。结果是一个比它需要的大得多的解决方案。

The problem usually comes in when we focus on making everyone happy, and at the same time fail to focus on small, specific target outcomes. The result is a solution that’s much bigger than it needs to be.

请记住,我们的目标是最大限度地减少我们构建的数量(我们的输出)并最大化我们从中获得的收益(结果和影响)。你的机会将分成许多可能的小故事。我们当然不会全部建造它们。那不会最小化输出,对吗?

Remember, our goal is to minimize the amount we build (our output) and maximize the benefit we get from doing it (the outcomes and impact). Your opportunity will break into lots of possible smaller stories. We certainly wouldn’t build them all. That wouldn’t be minimizing output, would it?

如果你没有砍掉比保留更多的想法,你可能没有正确地进行发现工作。

If you’re not cutting away more ideas than you keep, you’re probably not doing discovery work right.

总是有太多

There’s always too much

对不起,但是有。如果您长期从事软件开发,您可能已经知道这一点。我已经尝试了很多年,实际上是十多年,假装这不是真的。我已经放弃了。你也应该。但别担心:您有一些工具可以帮助您确定在给定的时间和人员的情况下构建的可行性。

I’m sorry, but there is. If you’ve been involved with software development for any length of time, you likely already know this. I’ve tried for many years, over a decade really, to pretend it’s not true. I’ve given up on that. You should, too. But don’t worry: you’ve got some tools that’ll help you identify something feasible to build given the time and people you have.

第 3 章,您了解到 Globo.com 使用地图来应对艰难的最后期限的方法。该公司专注于那个最后期限,接受它,并确定了一个能让它成功的结果。然后它把积压的订单切成薄片;也就是说,它删除了实现该结果所不需要的所有故事。这是它的最小可行解假设。这不仅仅是一个糟糕的、半生不熟的大创意版本——它是一个真正伟大的版本,非常专注于在巴西选举中取得成功。Globo 的人相信这对他们的业务、广告商、电视网络和用户都有价值。他们考虑了所有用户,并且非常有信心他们有一个可用的解决方案。通过切割他们的地图,他们找到了一个在给定时间和团队的情况下可行的解决方案。

In Chapter 3, you read about Globo.com’s approach to using a map to confront a tough deadline. The company focused on that deadline, embraced it, and identified an outcome that would let it be successful. Then it sliced up its backlog; that is, it cut away all the stories that weren’t necessary for it to reach that outcome. This was its minimal viable solution hypothesis. And it wasn’t just a crappy, half-baked version of the big idea—it was a really great version that was sharply focused on being successful for the Brazilian elections. The Globo folks believed it would be valuable to their business, their advertisers, TV networks, and their users. They’d thought about all their users, and were pretty confident they had a usable solution. And by slicing their map, they’d found a solution that was feasible to build given the time and teams they had. That intersection of valuable, usable, and feasible for a specific target set of customers, users, and uses is a viable solution.

可行意味着特定业务战略、目标客户和用户的成功。

Viable means successful for a specific business strategy, target customers, and users.

我们也可以考虑从第一个可行版本到第二个和第三个可行版本。但我们知道,一旦第一个版本上线,世界就会改变,这很好。但这也意味着我们需要根据我们创造的新世界重新考虑未来的发布。

We can think past that first viable release to second and third viable releases, too. But we know that once that first release goes live, the world will have changed, and that’s good. But it’ll also mean we’ll need to rethink the future releases in light of the new world we’ve created.

优先排序的秘诀

The secret to prioritization

靠近一点,因为我要低声说这个。

Step in close, because I’m going to whisper this.

知道这一点的人并不多——或者至少他们表现得好像不知道。也许他们只是在装傻,让人们失望。

Not many people know this—or at least they behave like they don’t. Maybe they’re just playing dumb to throw people off.

如果你一直在敏捷中徘徊开发一段时间后,您可能听说过“按业务价值确定故事的优先级”这一短语。该陈述在某种程度上是正确的,但是在您看到“业务价值”一词的地方,您应该用一些具体的内容来填充它。这是您和您的发现团队需要具体说明什么是有价值的地方。

If you’ve hung around in Agile development for a while you might have heard the phrase “prioritize stories by business value.” The statement is true, sort of, but where you see the words “business value,” you’re supposed to fill that in with something specific. This is where you and your discovery team need to say specifically what is of value.

让我们再看看疯狂咪咪。加里需要在资金用完之前尽快找到一种在特定市场上可行的产品。对 Gary 而言,可行意味着他拥有喜欢该产品并愿意为之付费的观众。他可以开始增加产品的受众,并因此增加他所赚取的收入。

Let’s look at Mad Mimi again. Gary needed to find a product that would be viable in a specific market soon, before he ran out of money. Viable for Gary meant he had an audience that liked the product and would pay for it. And he could begin to grow the product’s audience and the revenue he earned as a consequence.

正是这一业务目标与财务限制相结合,要求 Gary 专注于他支持的特定用户和用户活动。Gary 仍然对创建以 Mimi 命名的“音乐行业营销界面”寄予厚望。但他决定首先关注乐队经理,通过直接电子邮件营销向他的粉丝宣传他的乐队。在他这样做之后,他需要关注的具体功能变得清晰起来。

It’s that business goal combined with financial constraints that required Gary to focus on specific users and user activities he’d support. Gary still had high hopes of creating the “music industry marketing interface” that gave Mimi her name. But he decided to focus first on the band manager promoting his band using direct email marketing to his fans. After he did that, the specific functionality he needed to focus on became clear.

如果你刚才仔细听,你就会发现优先顺序的秘密。

If you were listening closely just now, you caught the secret to prioritization.

特定的业务成果推动关注特定用户、他们的目标以及他们将使用您的产品参与的活动。专注于这些活动会推动专注于用户成功所需的特定特性和功能。

Specific business outcomes drive focus on specific users, their goals, and the activities they’ll engage in with your product. Focus on those activities drives focus on the specific features and functionality users will need to be successful.

对于 Mad Mimi,Gary 深思熟虑地决定专注于取悦乐队经理来宣传他们的乐队。这就是他选择关注的具体价值。他没有使用模棱两可的术语“商业价值”。他用对他有价值的东西填补了空白。

For Mad Mimi, Gary made a deliberate decision to focus on delighting band managers promoting their bands. That’s the specific value he chose to focus on. He didn’t use that ambiguous term “business value.” He filled in that blank with what was of value to him.

大多数人犯的优先级错误是尝试首先确定功能的优先级。

The prioritization error that most people make is to try to prioritize features first.

在确定功能的优先级之前,先确定特定业务目标、客户和用户的优先级,然后是他们的目标。

Prioritize specific business goals, customers, and users, and then their goals, before prioritizing features.

没有标题的图片

下次当你发现有人问哪个功能更优先而不讨论业务目标、目标用户和他们的使用时,这就是你开始提问的提示。尽量不要表现得太自鸣得意。不是每个人都知道这个秘密。

The next time you catch someone asking which feature is higher priority without discussing business goals, target users, and their use, that’s your cue to start asking questions. Try not to act too smug. Not everyone knows this secret.

发现活动、讨论和工件

Discovery Activities, Discussions, and Artifacts

在发现过程中,您和您的团队可以创建很多活动和工件。这是一个快速表格,可以为您提供一些您可以做的事情的基本起点。不要做所有这些事情,因为它可能太多了。并且不要只做这些事情,因为可能有适合您的技能和背景的等效甚至更好的实践。但绝对不要只是坐在一个房间里写很多故事。那太疯狂了。

There are a lot of activities and artifacts you and your team can create during discovery. Here’s a quick table that’ll give you some basic starting points for the kinds of things you could do. Don’t do all these things, because it’s likely too much. And don’t do just these things, because there are likely equivalent or even better practices that suit your skills and context. But definitely don’t just sit in a room and write lots of stories. That’d be crazy.

框架的想法

Frame the idea

使用这些讨论来回顾您的企业为何构建软件、为谁构建软件以及您将如何衡量成功。

Use these discussions to review why your business is building the software, who it’s for, and how you’ll measure success.

  • 您正在解决的命名业务问题

  • Named business problems you’re addressing

  • 受影响的特定业务指标

  • Specific business metrics affected

  • 特定客户和用户的简短列表

  • Short lists of specific customers and users

  • 使我们能够衡量人们是否使用和喜欢这个新功能的指标

  • Metrics that will allow us to measure whether people use and like this new feature

  • 大风险和假设

  • Big risks and assumptions

  • 与业务利益相关者和主题专家的讨论

  • Discussions with business stakeholders and subject matter experts

了解客户和用户

Understand customers and users

通过讨论和研究来了解客户和用户,他们的需求,以及他们今天的工作方式。

Use discussions and research to understand customers and users, their needs, and how they work today.

  • 用户角色和描述列表

  • Lists of user roles and descriptions

  • 简单的用户配置文件或人物草图

  • Simple user profiles or person sketches

  • 简单的组织概况或 orgzona

  • Simple organizational profiles or orgzonas

  • 关于当今人们如何做事的故事地图——也称为旅程地图

  • Story maps about how people do things today—also known as journey maps

  • 用户研究和观察来填补我们不知道的

  • User research and observation to fill in what we don’t know

设想解决方案

Envision solutions

关注特定的客户和用户,然后构想对他们有帮助的解决方案。用文字和图片形象化解决方案。与客户和用户一起验证这些解决方案。

Focus on specific customers and users, and then envision solutions that will help them. Visualize solutions with words and pictures. Validate those solutions with customers and users.

  • 故事地图

  • Story maps

  • 用例和用户场景

  • Use cases and user scenarios

  • UI 草图和故事板

  • UI sketches and storyboards

  • 用户界面原型

  • UI prototypes

  • 建筑和技术设计草图

  • Architectural and technical design sketches

  • 建筑或技术原型

  • Architectural or technical prototypes

  • 与团队成员、用户、客户、利益相关者和主题专家进行大量协作

  • Lots of collaboration with team members, users, customers, stakeholders, and subject matter experts

最小化和计划

Minimize and plan

确定您认为的小型可行解决方案。充分估计以设置交付解决方案的预算。制定将风险降至最低的发展计划。

Identify what you believe is a small, viable solution. Estimate well enough to set a budget for delivering the solution. Create a plan for development that will minimize risk.

  • 用于切片的故事地图

  • Story maps used for slicing

  • 用于制定开发预算的估算

  • Estimation used for setting a development budget

发现是为了建立共同理解

Discovery Is for Building Shared Understanding

您还记得在一个没有人完全了解大局的软件项目中工作吗?您还记得有一次团队在开发过程中了解到他们没有计划的大量工作吗?通常,当这种事情过去发生在我身上时,我们会发现在我们团队中的所有人以及与我们合作的外部人员之间,我们都有答案。如果我们刚刚达成共识,我们本可以很容易地预见到我们遇到的问题。

Do you recall working on a software project where no one quite understood the big picture? Do you recall a time when the team learned halfway through development about a big chunk of work they hadn’t planned on? Often, when this stuff has happened to me in the past, we’ll find that between all of us in the team, and the outside people we collaborate with, we had the answers. We could have easily foreseen problems we ran into if we’d have just gotten on the same page.

第 1 章中 Gary 的故事有点关于 Gary 和他的交付团队对全局的理解不一致。即使是加里——那个在脑海中掌握产品愿景的人——也没有清楚地了解他的产品的规模和复杂性。将他的产品想象成一堆简单的模型帮助他和他所依赖的每个人在他们的脑海中形成了同样的大局。

Gary’s story in Chapter 1 is a bit about Gary and his delivery team not having shared understanding of the big picture. Even Gary—the guy who held the vision of the product in his head—didn’t have a clear understanding of the size and complexity of his product. Visualizing his product as a bunch of simple models helped him and everyone he was relying on get the same big picture in their minds.

对于你构建的某些东西,让每个人都了解你的客户和用户是谁以及你为他们考虑的解决方案的大局就足够了。但我需要警告你,你对你正在建造的东西的假设可能是错误的。别担心:我想告诉您一些策略,它们确实可以让发现实践发挥作用。这就是下一章的内容。

For some things you build, it may be enough to just get everyone on the same page about who your customers and users are, and the big picture of the solution you have in mind for them. But I need to warn you, your hypothesis about what you’re building is probably wrong. Don’t worry: there are a couple of strategies I want to tell you about that really make discovery practice work. And that’s what the next chapter is about.

第 15 章使用发现进行验证学习

Chapter 15. Using Discovery for Validated Learning

我误导了你。有点。

I’ve misled you. Sort of.

你们中的一些人可能已经阅读了上一章和之前的其他章节,并且您已经慢慢达到沸点,因为您知道我遗漏了什么。对于那个很抱歉。

Some of you may have been reading the last chapter, and other chapters before that, and you’ve been slowly reaching a boiling point because you know what I’m leaving out. Sorry about that.

我讲的关于MadMimi.com和 Globo.com 的故事都不完整。事实是,他们俩都使用发现对话来确定他们认为是最低限度可行的解决方案。但这些解决方案是否真的可行只是一个猜测。事实上,在我们实际发货并观察市场——我们的客户和用户——实际做的事情之前,所有这些都是猜测。最初的发现对话以及故事地图帮助他们进行了良好的初步猜测。但是,对于他们两人来说,这标志着真正发现可行产品的漫长旅程的开始。

The stories I told about MadMimi.com and Globo.com are both incomplete. The truth is that both of them used discovery conversations to identify what they believed was a minimum viable solution. But whether those solutions were actually viable or not was just a guess. In fact, all this stuff is a guess until we actually ship and observe what the market—our customer and users—actually does. Initial discovery conversations, along with story maps, helped them get to a good starting guess. But, for both of them, it marked the beginning of a much longer journey to really discover a viable product.

这导致我犯了人们犯的最大错误之一,实际上是相信他们的最小可行解决方案会成功。

This leads me to one of the biggest mistakes people make, and that’s actually believing their minimal viable solution will be successful.

大多数时候我们都错了

We’re Wrong Most of the Time

我和下一个相信我的伟大想法会成功的人一样内疚。事实上,过去我发布了很多我认为会非常成功的解决方案,但事实并非如此。它们也不是令人沮丧的失败——它们只是没有产生太大的影响。发生这种情况时,我和我的公司学会了换个角度看。不仅仅是我。我们认为我们添加的功能很有价值。但最后我们添加了一些人使用的功能,但大多数人没有,我们知道我们最终会支持我们产品的生命周期。

I’m as guilty as the next guy in believing my great ideas will be successful. The truth is that in the past I released lots of solutions I thought would be wildly successful, but they just weren’t. They weren’t dismal failures, either—they just didn’t make much of a difference. When this happened I, and my company, learned to look the other way. It wasn’t just me. We all thought the features we were adding would be valuable. But in the end we’d added a feature a few people used, but most didn’t, and we knew we’d end up supporting for the life of our product.

我的信念不是基于任何正式的科学研究,而是基于我自己的失败以及我在与其他公司合作时所观察到的,即我们所构建的东西很少是成功的或具有我们希望的真正影响。我估计最多 20%。然后,我们所做的另外 20% 的事情是真正的失败——导致负面影响的解决方案。我见过很多组织发布了一个新的、更好的网站版本,但发现销量下降,或者发布了一个新版本的产品,客户试用后要求退回旧版本。这就是我所说的失败。

My belief, not rooted in any formal scientific research or studies, but just in my own failures and what I observe working with other companies, is that very little of what we build is successful or has the real impact we hope for. I figure around 20 percent max. Then there is another 20 percent of things we do that are genuine failures—solutions that result in a negative impact. I’ve seen a variety of organizations that release a new, better version of their website and see sales decrease, or release a new version of their product that customers try and then demand the old version back. That’s the kind of failure I’m talking about.

但这是中间的 60%,无论是给予还是接受,这既不是成功也不是失败,这才是大问题。这是我们花费宝贵的开发资金创造的东西,最终希望我们没有。

But it’s that 60 percent in the middle, give or take, that is neither success nor failure that’s the big problem. This is the stuff that we spend valuable development money creating, and in the end wish we hadn’t.

没有标题的图片

Standish Group 发表在历史性“混沌”报告中的研究解释说,64% 到 75% 的功能很少或从未使用过。[ 14 ]而且,根据您查看的来源,75-90% 的软件初创公司都失败了。[ 15 ]

Research from the Standish Group published in historic “Chaos” reports explains that between 64 and 75 percent of features are rarely or never used.[14] And, depending on the source you look at, 75–90 percent of all software startups fail.[15]

当你想到这一切时,这一切都非常令人失望。难怪只是假装它在工作是大多数组织的选择策略。

All this is pretty disappointing when you think about it. No wonder just pretending it’s working is the strategy of choice for most organizations.

糟糕的过去

The Bad Old Days

在过去糟糕的日子里,我曾经有点像这样工作。我想出了一个好主意,或者实际上是其他人(例如我的首席执行官或重要客户)将他们的好主意交给了我。我会开始努力理解它并充实它。然后我和我的团队会建造它。它总是花费我们预期的两倍时间,但这是一个需要在后面的章节中处理的问题。我们会完成的。我们会发货。我们会庆祝。有时我们庆祝,然后发货。但无论哪种方式,我们都完成了。

In the bad old days, I used to work a bit like this. I’d come up with a great idea, or in reality, someone else like my CEO or a key customer handed me their great idea. I’d get to work making sense of it and fleshing it out. Then my team and I would build it. It always took twice as long as we expected, but that’s a problem to deal with in later chapters. We’d finish. We’d ship. We’d celebrate. Sometimes we celebrated, then shipped. But either way, we were done.

但后来事情真的开始发生了。通常发生的事情是人们抱怨我们提供的东西没有按照他们想要的方式工作。有时他们根本没有抱怨(我们后来发现这是没有人真正使用它的副作用)。然后我们会花很多时间假装我们成功了。对于你们中的一些人来说,这可能描述了你们公司今天的运作方式。老实说:这仍然是我经常重新投入工作的方式。不要告诉任何人。我应该是专家。

But then stuff actually started to happen. What usually happened was people complaining about what we’d delivered not working the way they wanted. Sometimes they didn’t complain at all (which we’d find out later was a side effect of no one really using it). We’d then spend a lot of time pretending we were successful. For some of you, that might describe the way your company works today. And I’ll be honest with you: it’s still the way I often fall back into working. Don’t tell anyone. I’m supposed to be an expert.

没有标题的图片

但是还有更好的选择。

But there are better alternatives.

同理心、专注、构思、原型、测试

Empathize, Focus, Ideate, Prototype, Test

多年前,一位潜在客户联系我,问我是否可以帮助它采用一种称为设计思维的过程。这个客户一直在使用典型的敏捷过程,并且做得非常好——“好”是因为它以可预测和高质量的方式交付。但它已经了解到,“你提供垃圾的速度越快,你得到的垃圾就越多。” 这听起来有点刺耳。换句话说,客户了解到,它构建的软件数量与它从中获得的结果和影响之间几乎没有关联。

Years ago, a potential client contacted me and asked me if I could help it adopt a process called design thinking. This client had been using a typical Agile process, and was doing it really well—“well” in that it was delivering predictably and with high quality. But it had learned that “the faster you deliver crap, the more crap you get.” That’s a little harsh sounding. To put it another way, the client had learned that there was little correlation between the quantity of software it built, and the outcome and impact it got from it.

当这个客户打电话时,我以我在用户体验设计和敏捷开发方面的专长而闻名。我心想:“我是设计师,我在思考,所以我一定是设计思维。” 但是我错了。客户不是这个意思。对我来说幸运的是,我没有大声说出我的想法。

When this client called, I was known for my specialty in user experience design and Agile development. I thought to myself: “I’m a designer, and I’m thinking, so I must be design thinking.” But I was wrong. That’s not what the client meant. Luckily for me, I didn’t say what I was thinking out loud.

设计思维是指一种工作方式,最初由一家名为 IDEO 的公司描述,后来由斯坦福大学的 d.school 描述和教授。如今,许多大学都在教授它,并在全球许多公司中使用它。

Design thinking refers to a way of working originally described by a company called IDEO, and then later described and taught by Stanford University’s d.school. These days, it’s taught in a number of universities and used in lots of companies worldwide.

没有标题的图片

设计思维过程有几个步骤,正如我解释的那样,这些步骤看起来显然是个好主意。但是,在实践中,我和大多数人倾向于做的恰恰相反。难怪事情经常变坏。

A design thinking process has several steps that, as I explain them, seem like obviously good ideas. But, in practice, what I and most people tend to do is the exact opposite. No wonder things go bad so often.

设计思维方法的第一步是同理心这不叫研究,我通常希望在设计过程中进行研究。之所以称为同理心,是因为做这项工作的一个关键结果是了解成为您产品的用户的真实感受。为此,您需要前往用户所在的地方,与他们会面,观看他们的工作,最好是与他们一起工作。现在,当然,如果你为外科医生开发软件,没有人会期望你成为一名业余外科医生。但是尽你最大的努力去理解穿上他们的鞋子是什么感觉。重要的是要记住,在传统研究中,尤其是定量的不干涉的研究中,我们得到的是数据,而不是总是同理心。

The first step of a design thinking approach is empathize. It’s not called research, which I’d normally expect from a design process. It’s called empathize because a critical outcome of doing the work is to understand how it really feels to be a user of your product. To do this you need to go to where users are, meet them, watch them work, and ideally work alongside them. Now, of course, if you build software for surgeons, no one expects you to become an amateur surgeon. But do your best to understand what it’s like to walk in their shoes. It’s important to remember that out of traditional research, especially the quantitative hands-off stuff, we get data and not always empathy.

直接与客户和用户交谈。亲身体验您正在帮助他们应对的挑战。

Talk directly to customers and users. Experience the challenges you’re helping them with firsthand.

下一步称为定义从我们在 empathize 期间所做的工作中,我们学到了很多东西。但我们需要理解它——建立共同的理解。为此,我们将通过大量协作来讲述故事、分享和提炼我们所学到的知识。然后我们将选择要关注的特定人员和问题。

The next step is called define. From the work we do during empathize, we learn a lot. But we need to make sense of it—to build shared understanding. And we’ll do this using lots of collaboration to tell stories, share, and distill what we’ve learned. Then we’ll choose specific people and problems on which to focus.

在此处使用故事地图来绘制当今人们做事的方式。在其中包括您所见所闻的详细信息。关注用户的痛点,以及他们寻求的回报。使用简单的角色来构建一个综合您所学知识的优秀示例用户。选择要关注的具体问题。

Use story maps here to map the way people do things today. Include in them details of what you saw and learned. Focus on the pain points users have, and the rewards they seek. Use simple personas to build a good example user that synthesizes what you’ve learned. Choose specific problems to focus on.

真正专注于一个或几个问题。具体说明。

Really focus on one or a few problems. State them specifically.

下一步是构思如果你在上一章中有密切关注,我们谈到了一种叫做设计工作室的简单实践。这是一个好的构思方法的例子。在常见的商业实践中,第一个想出可行想法的人就是赢家,想出很多可能的想法似乎是在浪费时间。如果您还记得您的第一个显而易见的解决方案是非常明显的,那么如果想出一个创新的解决方案真的很重要,那就想想过去吧。

The next step is ideation. If you were paying close attention in the last chapter, we talked about a simple practice called design studio. It’s an example of a good ideation approach. In common business practice where the first person to come up with a viable idea is the winner, it seems a waste of time to come up with lots of possible ideas. If you remember that your first obvious solutions are, well, obvious, then if really coming up with an innovative solution is important, think past that.

我喜欢使用故事地图作为构思的背景。使用显示痛苦、快乐和其他用户信息的地图,然后直接将想法集思广益。将解决方案的想法直接写在卡片或便签纸上,并将它们注入解决方案最相关的地图中。

I like using a story map as a backdrop for ideation. Use a map that shows pains, joys, and other information about users, and then brainstorm ideas directly into it. Write solution ideas directly on cards or stickies and inject them into the map where the solution is most relevant.

有意识地为客户和用户问题提出多种可能的解决方案。

Deliberately come up with multiple possible solutions to customer and user problems.

下一步是制作原型现在,我们可能都知道原型是什么,但我们常常在急于构建可运行的产品时忽略了创建原型。很遗憾,真的。对简单纸质原型的少量投资有助于我们思考解决方案。他们帮助我们开始亲身体验。用纸或最简单的原型制作工具构建简单的原型,可以帮助我们过滤掉很多行不通的想法。开始模拟使用产品的实际行为有助于您继续构思——想出让解决方案变得更好的想法。

The next step is to prototype. Now, we likely all know what prototypes are, but we often neglect creating them in the rush to get working products built. It’s a pity, really. Small investments in simple paper prototypes help us think through our solution. They help us begin to experience it ourselves. Building simple prototypes out of paper, or the simplest of prototyping tools, helps us filter out a lot of ideas that just won’t work. Beginning to simulate the actual act of using a product helps you continue to ideate—to come up with ideas to make the solution even better.

构建简单的原型来探索您的最佳解决方案。将原型提升到一定程度的保真度,使用户和客户能够评估该解决方案是否真正解决了他们的问题。

Build simple prototypes to explore your best solutions. Advance prototypes to a level of fidelity that allows users and customers to evaluate whether the solution really solves their problem.

最后一步是测试。我并不是说检查是否有错误。我的意思是了解您的解决方案是否真的解决了某人的问题。您可能会感到惊讶,即使存在错误,它也能做到这一点。当你有一个你认为可以解决你选择关注的问题的原型时,把这个原型放在将使用你的产品的人面前。这不完全是“展示和讲述”。而且绝对卖不出去。潜在用户需要将原型视为他们可以用来解决他们的问题之一的东西。他们需要用它来完成真正的任务。你实际上可以通过伪造很多来实现这一点。

The last step is to test. By that I don’t mean check to see whether there are bugs. I mean learn whether your solution really does solve someone’s problem. You might be surprised that it could do that even with bugs. When you’ve got a prototype that you believe solves the problems you’ve chosen to focus on, put that prototype in front of people who’ll use your product. This isn’t exactly “show and tell.” And it’s definitely not selling. Potential users need to recognize the prototype as something they could use to solve one of their problems. They need to use it to accomplish a real task. You can actually accomplish this by faking a lot of it.

将您的解决方案呈现在购买或使用您产品的人面前。不要指望他们一开始就会成功。迭代并改进它们。

Get your solutions in front of the people who will buy or use your product. Don’t expect them to be a success at first. Iterate and improve them.

除了这五个步骤之外,设计思维的一部分是一种工作方式它强调小型、多学科的协作团队使用简单的模型、草图和低保真度的记录和交流方式快速合作。作为我在第 12 章中描述的发现团队和其他合作者,您应该认识到这一点。你应该认识到他们的工作方式是强调建立共同理解的方式。

In addition to those five steps, part of design thinking is a way of working that emphasizes small, multidisciplinary collaborative teams working together quickly using simple models, sketching, and low-fidelity ways of documenting and communicating. You should recognize that as the discovery team and other collaborators I described in Chapter 12. You should recognize their way of working as one that emphasizes building shared understanding.

使用设计思维的元素可以帮助我们真正理解我们正在解决的问题,所以我们不会解决我们想象的人们遇到的问题。在我们投入大量资金构建功能齐全的可扩展解决方案之前,对解决方案进行原型设计和测试有助于我们验证我们正在构建人们真正重视并可以使用的解决方案。

Using elements of design thinking helps us really understand the problems we’re solving, so we don’t solve problems we imagine people have. Prototyping and testing solutions before we invest big in building full-featured scalable solutions helps us validate that we’re building solutions people really value and can use.

但是单靠设计思维会导致一些问题。

But design thinking alone can lead to some problems.

如何搞砸一件好事

How to Mess Up a Good Thing

设计过程已经存在了很长时间。设计思维作为一种通用的设计方法也有。一个好的设计过程可以比过去糟糕的日子有了巨大的进步。但是不要混淆过程和技巧。有一些可预测的设计流程失败方式。如果您看到一个好的设计过程花费太多时间并导致糟糕的结果,那么您可能会认为这些过程不起作用。这不是过程。

Design processes have been around a long time. Design thinking as a generalized approach to design has, too. And a design process done well can be a huge improvement over the bad old days. But don’t confuse process with skill. There are some predictable ways that design processes fail. If you’ve seen a good design process take way too much time and result in a bad outcome, then you might believe these sorts of processes don’t work. It’s not the process.

没有标题的图片

以下是一些扰乱设计过程的好方法:

Here are a few great ways to mess up a design process:

  • 在没有确定业务需求和目标客户的情况下开始。这会让你很难确定应该关注谁的优先级,也很难判断你是否找到了一个好的解决方案。
  • Start without framing the business needs and target customer well. This’ll make it hard to prioritize who to focus on, and hard to tell if you’re finding a good solution.
  • 花很多时间进行彻底的研究并理解你所学到的东西。你永远学不会学不完——那为什么要停下来呢?时间限制可能是个好主意。
  • Spend a lot of time doing thorough research and making sense of what you’ve learned. You’ll never run out of things to learn—so why stop? Time-boxing might have been a good idea.
  • 不要花任何时间与人交谈并向他们学习。毕竟,我们有很多数据,而且真的,我们的解决思路很棒。我们只需要继续设计它们。
  • Don’t spend any time at all talking to people and learning from them. After all, we’ve got a lot of data, and really, our solution ideas are great. We just need to get going on designing them.
  • 未能专注于特定问题,而是试图为很多人解决很多问题。你解决的问题越多越好,对吧?除了大问题通常会导致大解决方案。试图为有冲突需求的人解决问题可能会导致两个人都不喜欢的解决方案。
  • Fail to focus on specific problem, and instead try to solve lots of problems for lots of people. The more problems you solve the better, right? Except that big problems often result in big solutions. And trying to solve a problem for people with conflicting needs can result in a solution neither person likes.
  • 考虑多种解决方案,但只要求真正的设计师提供解决方案想法,因为他们是唯一受过良好想法训练的人。
  • Consider multiple solutions, but only ask real designers to contribute solution ideas, because they’re the only ones trained to have good ideas.
  • 不要浪费时间考虑多种解决方案,因为我们的想法非常好。
  • Don’t waste time considering multiple solutions, because the idea we have is so good.
  • 精美地制作一个看起来真的很真实的原型,但对于客户和用户来说还不够好,无法真正使用它。毕竟,当他们看到它时,他们会告诉我们它“看起来真的很可爱”。
  • Beautifully craft a prototype that really looks real, but doesn’t work well enough for customers and users to really use it. After all, when they see it, they tell us it “looks really lovely.”
  • 让自己和其他人相信这个经过充分研究、专业设计的解决方案会奏效。毕竟,您遵循了严格的设计过程。会出什么问题?
  • Convince yourself and then others that this well-researched, professionally designed solution will work. After all, you’ve followed a rigorous design process. What could go wrong?
  • 不用担心建造它要花多少钱。这是正确的解决方案,构建它的任何成本都是合理的。
  • Don’t worry about how much it’ll cost to build. It’s the right solution, and any cost to build it is justified.
  • 当您将解决方案交付给客户和用户,但没有看到您期望的结果时,请找出流程中的故障所在。或者更好的是,找一个你可以责怪的人或团体。
  • When you deliver the solution to customers and users, and don’t see the outcomes you expect, find the breakdown in the process that’s at fault. Or better yet, find a person or group you can blame.

我知道我在这里有点刻薄。但我坚决主张使用设计流程。而且,奇怪的是,我发现我经常是抱怨他们的人。我还可以说,我对列出的几乎所有失败都感到内疚。但是,在过去的几年里,我发现了一种改进它们的典型设计方法的转折点。

I’m being a bit snarky here, I know. But I’m a strong advocate for using design processes. And, oddly, I find I’m often the one complaining about them. I can also say that I’ve been guilty of almost all the failures listed. But, over the past few years, I’ve found a twist on typical design approaches that improves them.

经验证的短学习循环

Short Validated Learning Loops

埃里克·里斯 (Eric Ries) 是一本名为《精益创业》(皇冠企业)的书的作者。埃里克在他的书中描述了他是如何陷入我之前描述为“糟糕的过去”的陷阱的。作为一家初创公司的首席技术官,他帮助他的公司打造了他们认为是成功的产品。只有他们的目标客户和用户不这么看。事实上,他们的回应大多是愉快的反馈、糟糕的反馈和彻底的冷漠。绝对不是他们想要的结果和影响。

Eric Ries is the author of a book called The Lean Startup (Crown Business). In his book Eric describes how he fell into the trap I described earlier as the “bad old days.” As the CTO of a startup, he helped his company build what they believed to be a successful product. Only their target customers and users didn’t see it that way. In fact, they mostly responded with a mixture of pleasant feedback, bad feedback, and outright apathy. Definitely not the outcome and impact they were looking for.

Eric 的公司顾问之一是 Steve Blank。史蒂夫写了一本书,叫做顿悟的四个步骤(K&S 牧场),他在书中断言,你需要开发的第一件事不是产品,而是客户。他描述了一个过程,用于逐步验证您是否找到了对解决方案感兴趣的客户,然后验证您想到的解决方案是他们将购买、使用并告诉其他人的解决方案。Blank 将此称为经过验证的学习过程

One of Eric’s company advisors was Steve Blank. Steve had written a book called The Four Steps to Epiphany (K&S Ranch) in which he asserted that the first thing you need to develop isn’t a product, it’s customers. He described a process for progressively validating that you’ve found customers who are interested in a solution, and for then validating that the solutions you have in mind are the solutions they’ll buy, use, and tell others about. Blank referred to this as a validated learning process.

Eric Ries 对产品开发的最大贡献是将这种思维简化并“产品化”为这个简单的口头禅:构建-测量-学习Eric 强调减少完成这个简单学习周期所需的时间。传统设计流程中最大的缺陷之一花很长时间学习和设计——时间太长以至于你对解决方案非常执着,然后却无法验证这些解决方案是否确实带来了你想要的结果。典型的设计过程可能需要数周或数月的时间来验证解决方案的想法,而精益启动过程通常只需要几天时间。

Eric Ries’s biggest contribution to product development is simplifying and “productizing” that thinking into this simple mantra: build-measure-learn. Eric emphasized reducing the time it takes to get through this simple learning cycle. One of the biggest flaws in traditional design processes is spending a very long time learning and designing—so long that you become very attached to the solutions, and then failing to validate that those solutions really do bring about the outcomes you intended. Where a typical design process may take weeks or months to validate a solution idea, a Lean Startup process usually takes just days.

精益创业思维如何改变产品设计

How Lean Startup Thinking Changes Product Design

在过去糟糕的日子里,我们会想出一个好主意,建造它,并希望最好的。

In the bad old days, we’d have come up with a big idea, built it, and hoped for the best.

如果我们试图通过严格的设计流程来打破这个陷阱,我们就会尽力搁置我们的伟大想法,然后深入研究以了解我们正在解决的问题。

If we were trying to break out of that trap using a rigorous design process, we’d have done our best to set aside our great ideas, and then dig deep into research to understand the problems we’re solving.

这是我建议我们今天做事的方式,使用精益创业思维。

Here’s how I recommend we do things today, using Lean Startup thinking.

没有标题的图片

从猜测开始

Start by Guessing

是的,猜测。

Yes, guessing.

在过去糟糕的日子里,你会猜到并假装你不是。在设计过程中,您不允许自己去猜测。反正你会的。但你会假装你不是。所以别假装了。

In the bad old days, you’d have guessed and pretended you weren’t. In a design process, you’d not have allowed yourself to guess. You would have anyway. But you’d have pretended you weren’t. So just stop pretending.

其实不只是猜测。激情、经验和洞察力的结合——以及相当多的猜测——使事情顺利进行。我通常通过绘制简单的原型来假设和猜测我的用户是谁。我将通过构建简单的“现在”故事地图来描述我认为它们今天的工作方式。我将与其他对用户和客户有第一手经验的人合作来完成这项工作。而且,在某些情况下,我会直接让客户和用户参与进来。所以,其实我们团队的很多猜测根本就不是猜测。但这也不完全是我们过去所做的研究。我们会花几个小时到几天时间做这样的事情——而不是几周或几个月。

It’s actually not just guessing. It’s a mixture of passion, experience, and insight—along with a fair dose of guessing—that gets the ball rolling. I take my assumptions and guesses about who my users are, usually by sketching simple prototypes. I’ll describe how I think they work today by building simple “now” story maps. I’ll do this collaboratively with other people who have firsthand experience with users and customers. And, in some situations I’ll do this involving customers and users directly. So, in fact, many of our team’s guesses aren’t guesses at all. But it’s not exactly research like we used to do, either. We’ll spend hours to a couple of days doing stuff like this—never weeks or months.

在我们对谁将使用该软件达成共识并关注我们正在解决的问题之后,我们就会猜测解决方案。我们将使用设计思维原则——有意识地提出并考虑多种解决方案。但我们会尝试快速汇集我们认为最好的解决方案。有时我们无法决定一个单一的解决方案,而是选择几个。我们不会为此过度紧张,因为我们知道无论如何我们都可能错了。

After we’ve all got shared understanding about who will use the software and some focus in the problems we’re solving, we then guess at the solution. We’ll use principles of design thinking—deliberately coming up with and considering multiple solutions. But we’ll try to converge quickly on what we think our best solution is. Sometimes we’ll fail to decide on a single solution, and pick a couple. We don’t wring our hands about this too much, because we know we’re probably wrong anyway.

说出你的风险假设

Name Your Risky Assumptions

由于我们今天可能已经猜测了很多关于我们的用户和他们面临的挑战,所以我们将命名这些猜测。具体来说,我们将共同努力,将我们认为是真实的事情写成项目符号列表,但如果我们发现它们不是,那么我们将需要重新考虑一切。

Since we may have guessed a lot about our users and their challenges today, we’ll name those guesses. Specifically, we’ll work together to write a bulleted list of the things we believe are true, but if we find they aren’t, then we’ll need to rethink everything.

我们将对我们的解决方案做同样的事情。我们会考虑我们相信人们会如何回应它以及他们会如何使用它。我们将在脑海中形成一个关于我们认为他们将如何处理我们的解决方案的假设。我们还将讨论技术风险——会威胁到我们解决方案可行性的事情。

We’ll do the same with our solution. We’ll think about how we believe people will respond to it and how they’d use it. We’ll form a hypothesis in our minds about how we think they’ll behave with our solution. We’ll also discuss technical risks—things that would threaten the feasibility of our solution.

鉴于我们的客户、用户和我们的解决方案的风险和假设列表,我们将确定我们认为最大的风险是什么。

Given a list of risks and assumptions about our customers, our users, and our solution, we’ll identify what we think the few biggest risks are.

设计和构建一个小测试

Design and Build a Small Test

这是事情变得真正不同的地方。

Here’s where things get really different.

在过去糟糕的日子里,我们会计划并构建一个完整的产品。在设计过程中,我们会对整个产品或大部分产品进行原型制作。但是使用精益创业方法,我们的目标是尽快学习一些东西,我们将尽最大努力制作尽可能小的原型。在很多情况下,根本就很难将其称为原型。

In the bad old days, we’d have planned and built a whole product. In a design process, we’d have prototyped a whole product, or most of it anyway. But using a Lean Startup approach, where our goal is to learn something as quickly as possible, we’ll do our best to make the smallest prototype possible. In lots of cases, it’ll be hard to call it a prototype at all.

这是我在一个名为 ITHAKA 的非营利组织的朋友的例子。他们生产一种名为 JSTOR 的产品。如果您在过去十年被美国大学录取,您可能会在大学图书馆中使用 JSTOR 来查找您必须撰写的论文的文章和书籍。

Here’s an example from my friends at a nonprofit organization called ITHAKA. They make a product called JSTOR. If you’ve been enrolled in a US college in the last decade, you likely used JSTOR in your college library to find articles and books for a paper you had to write.

使用该产品的学生希望在任何地方都能轻松使用它——在咖啡店、家里或旅行时。但是从校外进入 JSTOR 对学生来说可能是一个挑战。它要求他们为他们的大学设置一个用户名和密码,这样当他们坐在咖啡店里时,他们就可以登录并访问他们大学获得许可的所有资源。JSTOR 团队已经有了解决方案,但使用起来有点棘手。他们想测试一种新的做事方式。

The students using the product wanted to easily use it from anywhere—at coffee shops, or at home, or when they traveled. But getting to JSTOR from outside the college could be a challenge for students. It required them to set up a username and password with their college so when they were sitting in a coffee shop, they could log in and get access to all the resources their university had licensed. The JSTOR team already had a solution, but it was a bit tricky to use. They wanted to test a new way of doing things.

他们对这些学生有以下假设:

They had these assumptions about those students:

  • 在咖啡店和宿舍工作
  • Worked from coffee shops and dorm rooms
  • 不知道他们可以从这些位置访问 JSTOR
  • Didn’t know they could access JSTOR from those locations
  • 或者,即使他们知道,他们也认为这很难
  • Or, if they did know, they thought it was difficult

他们对解决方案有以下假设:

They had these assumptions about their solution:

  • 会很容易学
  • Would be easy to learn
  • 对学生来说很明显,他们不用去图书馆就可以完全访问 JSTOR
  • Would be obvious to students that they were getting full access to JSTOR without being at their library

为了检验他们的假设,JSTOR 团队不需要构建软件——现在还不需要。他们需要与学生具体讨论他们在进行研究时所处的位置,尤其是在他们使用 JSTOR 时。该团队需要确认学生面临他们想象的挑战,并且鉴于此,学生认为 JSTOR 的解决方案理念可以解决这些挑战。

To test their assumptions, the JSTOR team didn’t need to build software—not yet. They needed to talk to students specifically about where they were when they were doing research, especially when they were using JSTOR. The team needed to confirm that students had the challenges that they imagined, and, given that, that students thought JSTOR’s solution idea would address those challenges.

该团队计划与很多学生交谈。而且,为了更容易和更一致地向学生描述问题和他们的解决方案,他们创建了一个简单的设计漫画。如果您还没有看过,设计漫画正是它听起来的样子。它看起来像漫画书中的几页。但是,它不是展示超级英雄与超级恶棍的战斗,而是展示真实的人用你的解决方案想法解决一个真正的问题。

The team planned on talking to lots of students. And, to make it easier and more consistent to describe the problem and their solution to students, they created a simple design comic. If you haven’t seen one, a design comic is exactly what it sounds like. It looks like a few pages from a comic book. But, instead of showing superheroes battling supervillains, it shows real people solving a real problem with your solution idea.

以下是 JSTOR 设计漫画中的几页(由 ITHAKA 提供,© 2014 ITHAKA,保留所有权利):

Here are a few pages from JSTOR’s design comic (reproduced courtesy of ITHAKA, © 2014 ITHAKA, all rights reserved):

没有标题的图片

团队设计的测试要求他们花一点时间采访学生以了解他们今天面临的挑战。然后,他们会与学生一起回顾这个场景,看看他们的解决方案是否能解决学生面临的挑战。他们没有构建完整的原型。他们确实担心他们的解决方案是否真的有用,而他们无法从漫画书中学到这一点。他们还有一些技术问题需要编写一些原型代码进行测试。但如果学生没有问题,并且对他们的想法反应不佳,那么这一切都无关紧要。

The test the team designed required that they spend a little time interviewing students to learn about their challenges today. And then, they’d review the scenario with the students to see if their solution looked like it would address the students’ challenges. They didn’t build a full prototype. They did have concerns that their solution would be really usable, and they couldn’t learn that from a comic book. They also had a few technical concerns that would require writing some prototype code to test. But none of that mattered if students didn’t have the problem, and didn’t respond well to their idea.

最小可行的测试解决方案就是 Lean Startup 所说的最小可行产品。是的,Eric Ries 知道这不是一个完整的产品。但是,当您的目标是学习时,它您可以构建用于学习的最小产品。

That smallest possible solution to test is what Lean Startup refers to as a minimum viable product. Yes, Eric Ries knows it’s not a whole product. But, when your goal is learning, it is the smallest product you could build to learn.

通过与客户和用户一起运行测试来衡量

Measure by Running Your Test with Customers and Users

将测试放在客户和用户面前。在早期工作中,这通常意味着安排面试和与人相处。如果您正在创建消费者解决方案,您可以进行客户拦截这是一种技术上的说法,就是去你的客户和用户所在的地方,阻止他们,并与他们交谈。当我一起工作的人去购物中心、咖啡店和旅游景点时,我已经标记了他们。

Put the test in front of customers and users. In early work this usually means schedule interviews and spend time with people. If you’re creating a consumer solution, you can do customer intercepts, which is a technical way of saying go to where your customers and users are, stop them, and talk to them. I’ve tagged along with people I work with as they go to shopping malls, coffee shops, and tourist attractions.

JSTOR 招募了学生和研究生,并先与他们交谈 30-60 分钟,以采访和了解他们今天的工作方式,以便团队可以确认他们对正在解决的问题的假设。然后他们引导学生浏览设计漫画,以获得他们对解决方案想法的回应。

JSTOR recruited students and grad students and spent 30–60 minutes talking with them first to interview and learn how they did things today so the team could confirm their assumptions about the problems they were solving. Then they stepped students through the design comic to get their response to the solution idea.

重新思考您的解决方案和您的假设

Rethink Your Solution and Your Assumptions

运行几次测试后,您将开始获得可预测的结果。如果你完全错了,你通常会很快学会。收回你学到的东西。将这些事实回溯到您认为您对用户的了解以及他们今天的工作方式。用它来重新考虑你的解决方案。然后,重新考虑您对用户和解决方案的假设。然后设计你的下一个测试。

After running your test a few times, you’ll begin to get predictable results. If you’re dead wrong, you’ll often learn that pretty quickly. Take back what you’ve learned. Roll those facts back into what you thought you knew about your users, and the way they work today. Use that to rethink your solution. Then, rethink your assumptions about users and solutions. Then design your next test.

在 JSTOR 人员进行测试后,他们了解到一些学生并没有他们认为的问题。通常这会是令人失望的消息,因为我们都讨厌犯错。但是,在精益创业方法中,这是个好消息。这非常好,因为他们在经过几天的思考和工作后发现自己错了,而不是在团队构建软件几周后才发现。

After the JSTOR folks ran their tests, they learned that some students didn’t have the problems they thought they did. Normally this would be disappointing news, because we all hate being wrong. But, in a Lean Startup approach, this is excellent news. It’s excellent because they found they were wrong after a couple of days of thinking and working, as opposed to finding out after weeks of a team building software.

如果你使用这种方法,你最大的挑战将是学会庆祝你正在学习的东西,而不是担心会犯错。

If you’re using this sort of approach, your biggest challenge will be to learn to celebrate what you’re learning as opposed to worrying about being wrong.

在精益创业方法中,不学习通常是最大的失败。

In a Lean Startup approach, failing to learn is frequently the biggest failure.

在精益创业方法中,构建意味着构建尽可能小的实验你可以。度量可以是从工作软件中收集的分析、从访谈和/或面对面的原型测试中直接观察到的。学习是我们对信息所做的事情。这是对我们的假设的重新思考,并改革我们认为是未来最好的解决方案。

In a Lean Startup approach, build means build the smallest possible experiment you can. Measure may be analytics gathered from working software, direct observations from interviews and face-to-face testing of prototypes, or both. Learning is what we do with the information. It’s the rethinking of our assumptions and reforming what we believe to be a best solution going forward.

故事和故事地图?

Stories and Story Maps?

您可能会问,“这一切中的故事和故事地图在哪里?” 你问的是对的。

You might be asking, “Where are the stories and story maps in all this?” And you’d be right to ask.

在经过验证的学习方法中,您将不断讲故事关于您的用户是谁,他们在做什么以及为什么。您将使用故事地图来讲述有关人们当今如何工作以及您想象他们将如何使用您的解决方案的更大故事。当需要构建原型时,您将使用故事和故事对话来具体商定您正在构建的原型应该是什么样子,以及您将检查哪些内容以确认原型已完成。在您了解故事是一种工作方式之后,您会发现很难判断您何时使用或不使用它们。

Throughout a validated learning approach, you’ll be constantly telling stories about who your users are, what they’re doing, and why. You’ll use story maps to tell bigger stories about how people work today, and how you imagine they’ll use your solution. When it comes time to build prototypes, you’ll use stories and story conversations to agree specifically on what the prototype you’re building should look like, and what you’ll check to confirm the prototype is done. After you understand that stories are a way of working, you’ll find it’s difficult to tell when you are or aren’t using them.

不过,我们在发现过程中使用故事的方式存在很大差异。通常,当我们使用它们时,我们会与开发人员、测试人员和许多其他人讨论我们打算构建并投入生产的软件。我们将非常努力地工作以确保我们达成共识。我们将详细介绍如何构建软件,这样我们就可以学到足够多的知识来预测地估计需要多长时间。通常我们会讨论一些故事,这样我们就可以在两周的冲刺或迭代中完成多少达成一致。但是我们在发现过程中的工作方式更快。我们希望在数小时而不是数天内构建简单的原型。即使是我们希望使用代码和实时数据构建的原型也需要几天而不是几周的时间。我们正在建设中学习,我们预计我们的大部分想法都会失败,或者至少,需要一些调整才能成功。所以我们专注于快速合作,快速达成一致,并尽量减少手续。

There is one big difference in the way we use stories during discovery, though. Usually when we’re using them, we’re talking with developers, testers, and lots of others about the software we intend to build and put into production. We’ll work pretty hard to make sure we’ve got shared understanding. We’ll get into a lot of details about how we’ll build the software so we can learn enough to predictably estimate how long it’ll take. Usually we’ll talk about a number of stories so we can agree on how much we can get done in a two-week sprint or iteration. But the way we’re working during discovery is faster. We hope to build simple prototypes in hours, not days. Even the prototypes we build using code and live data we hope will take days, not weeks. We’re building to learn, and we expect most of our ideas to fail, or at minimum, need some adjustment to be successful. So we focus on working together quickly, agreeing quickly, and minimizing the formality.

在发现和验证学习期间,您可能会不断讲故事、分解想法并将其分解为可构建的小块,并就构建的确切内容达成一致。你会做得太快以至于你不会清楚你正在使用故事。但你是。

During discovery and validated learning, you may be telling stories constantly, breaking ideas and work down into small buildable pieces, and agreeing on exactly what to build. You’ll be doing it so fast that it won’t be clear you’re using stories. But you are.




[ 14 ] Jim Johnson,Standish Group 主席,“ROI,这是你的工作”(主题演讲),第三届极限编程国际会议,意大利阿尔盖罗,2002 年 5 月 26 日至 29 日。

[14] Jim Johnson, Chairman of the Standish Group, “ROI, It’s Your Job” (keynote), Third International Conference on Extreme Programming, Alghero, Italy, May 26–29, 2002.

[ 15 ] Deborah Gage,“风险投资的秘密:4 家初创公司中有 3 家失败”,《华尔街日报》,2012 年 9 月 20 日, http: //on.wsj.com/UtgMZl

[15] Deborah Gage, “The Venture Capital Secret: 3 Out of 4 Start-Ups Fail,” Wall Street Journal, September 20, 2012, http://on.wsj.com/UtgMZl.

第 16 章提炼、定义和构建

Chapter 16. Refine, Define, and Build

那么现在怎么办?如果故事是为了计划和促进讨论以构建软件,那么我们所做的一切似乎都是在谈论很多。

So, now what? If stories are for planning and facilitating discussions in order to build software, all we seem to be doing is lots of talking.

卡片、对话、更多卡片、更多对话……

Cards, Conversation, More Cards, More Conversations…

你的第一组对话帮助你理解了一个机会。你谈到了谁会使用你的产品,并想象他们将如何使用它来完成对他们有价值的事情。你们的谈话深入到足以将大机会分解成足够小的部分,这样你就可以分辨出哪些部分对于下一个产品发布很重要,哪些部分无关紧要。您将描述下一个可行版本的故事收集到版本积压中。

Your first bunch of conversations helped you make sense of an opportunity. You talked about who’d be using your product, and imagined how they’d use it to accomplish something valuable to them. Your conversations went deep enough to break the big opportunity into parts that were small enough that you could tell which parts were important to be in a next product release, and which didn’t matter so much. You collected the stories that described that next viable release into a release backlog.

如果你很聪明,我知道你很聪明,那么你接下来的谈话会更深入地讨论软件的外观、它的行为方式,以及它如何融入你现有的产品和软件架构。你在密切关注有风险的事情的情况下进行了这些对话。您将故事分割成您可以尽早构建的部分,这将帮助您更快地了解更多。因为你很聪明,你将你的发布积压分成故事,以便在早期学习,在中间建立,然后再完善。

If you’re clever, and I know you are, your next conversations went deeper into what the software might look like, how it would behave, and how it might knit into your existing product and software architecture. You had these conversations with a close eye on the risky stuff. You sliced up the stories into the parts that you could build early that would help you learn more, faster. And because you’re clever, you segmented your release backlog into stories to take on early to learn, in the middle to build up, and later to refine.

但现在它变得真实了。是时候进行我们最好的最后一次对话了。

But now it gets real. It’s time to have our best last conversations.

切割和抛光

Cutting and Polishing

我们想着手建造这些东西,我们知道如果我们能够简明扼要地描述我们想要构建的内容,那么构建我们讲故事所描述的软件将会顺利且可预测地进行。但是,在所有这些对话之后,我们留下的故事感觉有点粗糙。我们可能还没有足够详细地讨论它们中的任何一个,以准确了解它们是什么,它们不是什么,并真正预测它们将花费多长时间来构建。但我们有一台神奇的机器可以解决这一切。

We’d like to get to work building these things, and we know that building the software that our storytelling describes will go smoothly and predictably if we can concisely describe exactly what we’d like to build. But, after all these conversations, the stories we’re left with feel a little rough around the edges. We likely haven’t talked about any of them in enough detail to understand precisely what they are and what they aren’t, and really predict how long they’ll take to build. But we’ve got a magical machine that’ll fix all this.

我想让你想象一个设计精美的小机器。我们会将发布积压的参差不齐、粗略的故事放入左侧的大漏斗中。然后,在机器内部,我们会听到轻微的摩擦声和咔嗒声。但随后从右侧的小喷口中流出小而光滑的小金块。这些小块是团队成员可以挑选并用于可预测地构建高质量软件的东西。

I want you to picture an elegantly designed little machine. We’ll drop jagged, rough stories from our release backlog into a big funnel on the left side. Then, inside the machine, we’ll hear a little grinding and clattering. But then out of a little spout on the right side comes small, polished little nuggets. These little nuggets are the things that team members can pick up and use to predictably build high-quality software.

这台机器从外面看起来很神奇。但是,在内部,您和您的团队正在进行一些严肃的切石和抛光讨论。隐藏在这台机器内部的特殊秘密机构是一个故事工作室

This machine looks magic from the outside. But, on the inside, you and your team are having some serious rock-cutting and polishing discussions. The special, secret mechanism hidden inside this machine is a story workshop.

您可能还记得第 11 章,故事研讨会是小型的、富有成效的对话,合适的人在一起最后一次讲故事,并在此过程中做出关于他们将选择构建什么的所有艰难决定。这些是导致确认的深层故事对话。最后,我们将进入卡片-对话-确认流程中的第三个C。正是这种C帮助我们真正切割并为这些岩石添加抛光剂。

As you might recall from Chapter 11, story workshops are small, productive conversations where the right people work together to tell the stories one last time, and in the process make all the tough decisions about exactly what they’ll choose to build. These are the deep story conversations that result in confirmation. Finally, we’re getting to that third C in the card-conversation-confirmation flow. And it’s this C that helps us really cut and add the polish to these rocks.

工作坊故事

Workshopping Stories

您需要一个小组,其中包括一名开发人员、一名测试人员以及了解用户和 UI 外观和行为的人员——某些组织中的 UI 设计师或业务分析师。当小组人数足够少,可以在白板前有效地协同工作时,这种方法效果最好。一般是三五个人。

You’ll need a small group that includes a developer, a tester, and people who understand users and how the UI will look and behave—UI designers or business analysts in some organizations. This goes best when the group is small enough to work together effectively in front of a whiteboard. That’s usually three to five people.

没有标题的图片

这是一个研讨会,而不是在会议中。会议这个词已经成为非生产性协作的委婉说法。故事研讨会需要充满大量富有成效的讨论、挥手、白板绘图和素描。我们需要共同努力来决定我们要建造什么。我们必须以坚定的共同理解结束这次对话,我们需要空间来进行那些富有成效的文字和图片对话。

This is a workshop, not in a meeting. Meeting is the word that has become a euphemism for unproductive collaboration. A story workshop needs to be filled with lots of productive discussion, hand waving, whiteboard drawing, and sketching. We’ll need to work together to decide exactly what we’ll build. We’ve got to come out of this conversation with solid shared understanding, and we’ll need space to have those productive words-and-pictures conversations.

在之前的所有这些对话中,我们讨论了细节,但希望我们能够克制到足够深入以做出当时需要的决定。我们现在所做的决定集中于回答这个问题:我们到底要建造什么?

In all those conversations prior to now, we talked through details, but hopefully we had the restraint to go just deep enough to make the decisions we needed to at the time. The decisions we’re making now focus on answering the question: exactly what will we build?

正是在这次谈话中,你会发现你的故事太大了。我的意思是它比我们希望看到的理想规模要大——几天或更短的时间来开发。好的,它并不总是太大。但是,如果您只是假设它会是,那么当它不是时您会感到惊喜。令人高兴的是,房间里有合适的人来帮助您将这个故事分解成更小的故事,这些故事可以在团队正在共同构建的不断增长的产品中交付、测试和演示。

It’s during this conversation that you’ll find out your story is too big. By that I mean it’s bigger than the ideal size we like to see going into development—a couple of days or less to build. OK, it’s not always too big. But, if you just assume it will be, then you’ll be pleasantly surprised when it’s not. Happily, you have exactly the right people in the room to help you break down this story into smaller stories that can be delivered, tested, and demonstrated in the growing product the team is working together to build.

Sprint 还是迭代计划?

Sprint or Iteration Planning?

一些敏捷实践者在迭代计划或冲刺计划等计划会议期间完成这些关键故事对话。如果您正在与高效协作的团队合作,并且在深入了解他们的产品的情况下参与讨论,那么这会非常有效。对于我合作多年的团队,这就是我们做事的方式。

Some Agile practitioners accomplish these critical story conversations during planning sessions like iteration planning or sprint planning. That works pretty well if you’re working with teams that work effectively together and come into the discussion with a good understanding of their product. For teams I worked with for years, that’s the way we did things.

但我从敏捷团队那里听到的最大抱怨之一是,这些计划会议通常是漫长而痛苦的事情。在某些时候,每个人都同意构建什么,即使他们没有共同的理解,只是为了让这个痛苦的会议停止。

But one of the biggest complaints I hear from Agile teams is that these planning meetings are often long, torturous affairs. At some point everyone agrees on what to build, even if they don’t have shared understanding, just to make this torturous meeting stop.

人群不合作

Crowds Don’t Collaborate

痛苦的冲刺计划会议已经成为一种常见的功能障碍,以至于许多团队明智地选择在会议前几天进行这些故事讨论。他们通常将这些安排在他们的日历中,作为预先计划会议、积压工作梳理或积压工作改进会议。但是,经常发生的情况是,他们只是将他们在计划会议期间所厌恶的折磨转移到了另一天。雪上加霜的是,团队成员被要求从他们目前的生产性工作中休息一下,坐下来忍受这种折磨。难怪他们对此并不兴奋。

The torturous sprint planning meeting has become such a common dysfunction that many teams sensibly choose to have these story discussions in the days preceding the meeting. They often have these scheduled in their calendars as pre-planning meetings, backlog grooming, or backlog refinement meetings. But, too often, what happens is they’ve simply moved the same torture they hated during the planning meeting to a different day. To add insult to injury, team members are asked to take a break from their current productive work to sit through this torture. No wonder they’re not excited about it.

问题不在于故事对话很难。好吧,实际上他们有时会很难。但是,所有的谈话都因为试图包括太多人而变得更加艰难。如果其中许多人没有兴趣或没有动力参与,那你就完蛋了。你知道我说的那些人——那些假装我们看不到他们在桌子底下玩智能手机的人。

The problem isn’t that story conversations are hard. Well, actually they can be pretty hard at times. But all conversations are made tougher by trying to include too many people. If many of those people aren’t interested or motivated to participate, you’re doomed. You know the people I’m talking about—the ones pretending we can’t see them playing with their smartphones under the table.

允许团队成员选择加入这些对话。如果以后他们抱怨所做的决定,请确保下次邀请他们到场。

Allow team members to opt in to these conversations. If later they complain about the decisions made, make sure you invite them to be there next time.

如果每个人都想参与,请尝试使用像下面边栏中描述的那样的鱼缸协作模式。这样,感兴趣的人就可以顺路过来,如果他们愿意,就可以参加,如果他们发现他们没有错过任何令人兴奋的事情,就可以离开。

If everyone wants to participate, try using a fishbowl collaboration pattern like the one described in the following sidebar. This way, interested people can drop by, participate if they want, and leave if they find they’re not missing anything exciting.

分裂和变薄

Split and Thin

还记得第 8 章中关于蛋糕和纸杯蛋糕的讨论吗?现在是时候将这些蛋糕分解成最小的纸杯蛋糕了。现在——当我们拥有开发人员、测试人员和其他真正能够构建软件的人时——我们才能真正想象我们如何分解这个故事。

Remember the cake and cupcakes discussion from Chapter 8? Now’s the time to break down those cakes to the smallest cupcakes you can. It’s now—when we’ve got developers, testers, and others who can really build the software—that we can really imagine how we could break down the story.

请记住,软件是“软的”。好吧,它不像海绵或纸杯蛋糕那样柔软。理想情况下,它更像是一个相当大的文档或一本书。如果你正在写一本书,就像我现在正在尽我最大的努力那样,你就不会试图一次完成所有的事情。你可能会坐下来一次写一章。事实上,我会一次写一章,彼得,我称职的、支持我的编辑,会审阅我所写的内容,并提出更正和建议。

Remember that software is “soft.” Well, it’s not soft like a sponge or a cupcake. Ideally, it’s more like a rather large document or a book. If you were writing a book, like I’m doing my best to do right now, you wouldn’t try to do it all at one time. You might sit down and write a chapter at a time. In fact I’ll write a chapter at a time, and Peter, my competent, supportive editor, will review what I’ve written and make corrections and suggestions.

但是这一章还没有“完成”。离得很远。

But then the chapter’s not “done.” Far from it.

我需要回过头来找出应该有插图的地方。我需要弄清楚是否应该添加脚注、参考文献、术语表或索引项。然后出版商的其他编辑将回顾每一章,进行最后的改进。我很自然地把工作分开来迭代完成,这样我就可以更快地看到整本书的成型。

I’ll need to go back through and figure out where there should be illustrations. I’ll need to figure out if I should add footnotes, references, glossary terms, or index items. Then other editors from the publisher will go back through each chapter, making final refinements. I’ve naturally split up the work to do it iteratively so that I can see the whole book take shape sooner.

您正在阅读“优化、定义和构建”一章。如果您现在正在阅读它,则希望它已经完全成熟。如果我要考虑我的最终验收标准,我会说它应该是:

You’re reading the “Refine, Define, and Build” chapter. And if you’re reading it now, it’s hopefully fully baked. If I were to think about my final acceptance criteria, I’d say it should be:

  • 由我编辑和理解
  • Edited and understandable by me
  • 由我的编辑编辑和理解
  • Edited and understandable by my editors
  • 插图支持,帮助读者直观地理解要点
  • Supported by illustrations that help enable readers to visualize points
  • 由索引支持,读者可以使用它来查找章节中的术语
  • Supported by an index readers could use to find terms in the chapter
  • 由词汇表支持,读者可以使用该词汇表查找本章中介绍的术语的定义
  • Supported by a glossary that readers could use to look up definitions of terms introduced in the chapter

废话,这是很多工作。即使我现在将这些内容输入初稿,我也意识到我还有很多工作要做。但我不想在继续下一章之前完成所有这些,因为我想看看整本书是如何联系在一起的。因此,我将把它分解成“纸杯蛋糕”——还没有准备好发货的小而完整的部分,但这增强了我的信心,让我相信我在阅读本书时走在正确的轨道上。

Crap, that’s a lot of work. Even as I type those things into the first draft now, I realize I’ve got lots of work to do. But I don’t want to do all of it before moving on to the next chapter, because I’d like to see how the whole book is hanging together. So I’ll break it into “cupcakes”—small, complete parts that aren’t ready to ship, but that boost my confidence that I’m on the right track as I move through this book.

我会把我的工作分解成这样的故事:

I’d break down my work into stories like this:

  • 提炼、定义、构建初稿
  • Refine, Define, Build first rough draft
  • 完善、定义、构建第二个完善的草案
  • Refine, Define, Build second refined draft
  • 用插图改进、定义、构建
  • Refine, Define, Build with illustrations
  • 结合审阅者的反馈改进、定义、构建
  • Refine, Define, Build with reviewer feedback incorporated
  • 优化、定义、构建索引词
  • Refine, Define, Build index terms
  • 提炼、定义、构建词汇表术语
  • Refine, Define, Build glossary terms
  • 完善、定义、构建最终草案
  • Refine, Define, Build final draft

我可以讲故事的每一件事都描述了它的样子,并思考了我(在 Peter 的编辑协助下)必须完成的步骤,以完成这些较小的版本和对章节的改进。您可以看到,随着每件事的完成,本章会逐渐变得更加完善,并且更接近于发布。理论上,列表中的第一个故事完成后,您可以看到并消费一些东西。但我不会那样对你。它不会很漂亮,你的反应也不会很好。

Each one of those things I can tell a story about describes what it looks like, and thinks through the steps I (with Peter’s editing assistance) must accomplish to finish each of these smaller versions and improvements to the chapter. And you can see that as each thing is completed, the chapter gets progressively more refined and closer to releasable. In theory, there’s something you could see and consume after the first story in the list is done. But I wouldn’t do that to you. It wouldn’t be pretty, and your reactions wouldn’t be good.

最后,由于我知道您在游戏中处于领先地位,您可能已经注意到较小的纸杯蛋糕大小的故事列表看起来很像本章的验收标准。这就是这里的魔力。正是对验收标准的讨论揭示了我们如何将工作分解成更小的部分,我们可以在整个过程中创建和检查。

Finally, since I know you’re on top of your game, you may have noticed that the list of smaller, cupcake-sized stories looks a lot like the acceptance criteria for the chapter. That’s the magic here. It’s the discussion of the acceptance criteria that reveals how we could break down the work into smaller parts we could create and inspect along the way.

在整个过程中检查您的工作很重要,这样您就可以对其进行评估并进行课程更正。您应该已经看到我最初在这里写的那个非常愚蠢的例子。但是你永远不会看到它,因为我写了它,检查了它,然后删除了它。

It’s important to inspect your work along the way so you can evaluate it and make course corrections. You should have seen the really stupid example I’d originally written here. But you’ll never see it because I wrote it, inspected it, and then removed it.

在传统的软件过程中,这种“检查和删除”的东西被称为不良需求。但是,当您戴上敏捷帽子时,这只是学习和迭代改进。

In a traditional software process, that “inspecting and removing” stuff would be called bad requirements. But, when you’ve got your Agile hat on, it’s just learning and iterative improvement.

当你真的有很好的故事讨论时,我知道你会的,故事研讨会结束时,您应该拥有由大量额外文档和模型支持的大小合适的故事,以及描述您将如何检查该故事以确认它已完成的验收标准。有时需要一些外部研究、分析和设计工作支持的几个研讨会才能达成一致,但这没关系。切割和抛光需要时间,也需要更多的耐心。

When you’re really having good story discussions, and I know you will, at the end of a story workshop you should have right-sized stories supported by lots of extra documentation and models, and by acceptance criteria that describe how you’ll check this story to confirm it’s done. Sometimes it’ll take a couple of workshops supported by a little outside research, analysis, and design work to arrive at agreement, but that’s OK. Cutting and polishing takes time, and a bit more patience.

在交付期间使用您的故事地图

Use Your Story Map During Delivery

使用地图与您的交付团队建立共识。我经常听到在敏捷过程中工作的团队成员说他们有多喜欢协作,以及他们觉得有多高效,因为他们每隔一两周就会看到并演示工作软件。但随后他们接着说,“我觉得我失去了全局。我所看到的只是我们制造的产品的这些小部分。” 使用地图让团队了解您正在处理的整个产品或功能。如果他们了解这些决策适合的背景,他们将做出更好的战术设计和开发决策。

Use a map to build shared understanding with your delivery team. I often hear from team members working in an Agile process how much they like collaborating, and how productive they feel because every week or two they see and demonstrate working software. But then they follow that up with statements like, “I feel like I’ve lost the big picture. All I see are these little parts of the product we build.” Use a map to give the team the visibility of the whole product or feature you’re working on. They’ll make better tactical design and development decisions if they understand the context those decisions fit into.

使用地图可视化进度

Use a Map to Visualize Progress

当您开始构建产品版本时,地图会成为一个很好的可视化仪表板,以显示您已构建和未构建的内容。

As you begin to build your product release, the map makes a good visual dashboard to show what you have and haven’t built.

一些团队在开发完成时从地图主体中删除详细故事。这样,当他们查看地图时,他们所看到的就是剩下要建造的东西。

Some teams remove detailed stories from the body of the map as they bring them into development to complete. That way, when they look at the map, all they see is what’s left to build.

其他团队喜欢将地图留在原地并使用钢笔或彩色贴纸标记他们完成的故事。当他们退后一步查看地图时,他们会看到已完成的事情和剩下要做的事情的可视化。

Other teams like leaving the map in place and using pens or colored stickers to mark the stories they’ve completed. When they step back and look at the map, they see a visualization of what’s done, and what’s left to do.

没有标题的图片

使用地图确定下一个要建造的故事。每周,产品负责人都需要评估正在进行的开发工作的进展情况,并决定下一步要重点关注什么。当地图可视化进度时,扫描它以查找需要更多关注的区域会更容易一些。这有点像画家。如果你能退后一步,仔细观察整幅画,就更容易找出下一步从哪里开始工作。

Use the map to identify the next stories to build. Every week, product owners will need-assess the progress of ongoing development work, and make decisions about what’s important to focus on next. When the map visualizes progress, then it’s a bit easier to scan it to look for areas that need more focus. It’s sort of like being a painter. If you can step back and take in the entire painting, it’s easer to figure out where to start working next.

在故事研讨会期间使用简单的地图

Use Simple Maps During Story Workshops

在每个开发周期中,您将在地图中确定接下来应该处理的故事。您将把这些故事带入您在故事研讨会期间进行的最后一次最佳对话中。

Each development cycle, you’ll identify stories in the map you should work on next. You’ll carry those stories into those last best conversations you’ll have during story workshops.

在研讨会期间构建的一个简单的可视化是一张简单的地图。您可能只映射了用户使用您正在讨论的功能所采取的三四个步骤。但是能够指向墙上显示流程的便利贴有助于讨论更快地进行。当您开始讨论验收标准时,将它们写在便利贴上并将它们添加到这张迷你地图中。最后,您将拥有一个简单的可视化效果来支持您在本次研讨会中进行的对话。

An easy visualization to build during that workshop is a simple map. You might be mapping only the three or four steps the user takes using a feature you’re discussing. But being able to point to sticky notes on a wall that show the flow helps the discussion move faster. As you begin to discuss acceptance criteria, write them on sticky notes and add them into this mini-map. In the end, you’ll have a simple visualization that supports the conversation you had in this workshop.

第 17 章故事实际上就像小行星

Chapter 17. Stories Are Actually Like Asteroids

如果您到了一定年龄,您可能会深情地回忆起玩过一款名为Asteroids的早期视频游戏。在这里陪我一会儿。我保证这是相关的。

If you’re of a certain age, you may fondly recall playing an early video game called Asteroids. Stick with me here for a moment. I promise this is relevant.

小行星游戏中,您的代表是一艘漂浮在外太空深处的小船。但是你被困在一片巨大的小行星领域,你需要开枪逃生!如果你射击一颗大的小行星,它会爆炸成几颗较小的小行星。而且,让事情变得更复杂的是,这些较小的小行星移动得更快,而且方向不同——这让你更难避免被击中。如果你射击其中一颗较小的小行星,它会分裂成更小的小行星,这些小行星向不同方向移动得更快。很快,屏幕上就充满了各种大小的小行星,这些小行星向各个可能的方向飞来飞去。令人高兴的是,当你射击最小的小行星时,它们会完全爆炸并帮助清理这个烂摊子。

In the game Asteroids, you’re represented by a little ship floating deep in outer space. But you’re stranded in a field of huge asteroids, and you need to shoot your way out to survive! If you shoot a big asteroid, it explodes into a few smaller asteroids. And, to make things more complicated, these smaller asteroids move faster, and in different directions—which makes it harder for you to keep from getting hit. If you shoot one of those smaller asteroids, it’ll break into even smaller asteroids that move even faster in different directions. Pretty soon, the screen is full of asteroids of all different sizes flying in every possible direction. Happily, when you shoot the tiniest asteroids, they blow up completely and help clear away this mess.

没有标题的图片

一个非常糟糕的小行星策略是射击所有的大石头并将它们分解成小石头。屏幕上到处都是许多飞来飞去的小石头,你会死得又快又痛苦。

A really bad asteroid strategy is to shoot all the big rocks and break them down into small rocks. The screen fills with lots of small rocks flying every which way, and you’ll die a quick and painful death.

一个非常糟糕的产品积压管理策略是分解所有大故事,使它们足够小以适应下一个开发周期。你的积压工作将充满大量飞来飞去的小故事,你会死的。好吧,你实际上不会死,但你会被许多不必要的复杂性活埋。你和其他人都会抱怨在所有这些微小的细节中失去了大局。

A really bad product backlog management strategy is to break down all the big stories so they’re small enough to fit into the next development cycle. Your backlog will fill with lots of small stories flying every which way, and you’ll die. Well, you won’t actually die, but you’ll be buried alive in a lot of needless complexity. You and everyone else will complain about losing the big picture amid all these tiny details.

逐步、及时地分解故事。

Break stories down progressively, and just in time.

在每个故事讨论和拆分阶段,您都会牢记一个目的:

At each story discussion and splitting stage, you’ll do so with a purpose in mind:

  1. 对于机会,您将讨论他们是为谁服务的,他们解决了什么问题,以及他们是否与您的业务战略保持一致。在这一点上拆分臃肿的机会可能是有意义的。
  2. For opportunities you’ll discuss who they’re for, what problems they solve, and if they’re well aligned with your business strategy. It may make sense to split bloated opportunities at this point.
  3. 在发现期间,您将讨论谁使用该产品、为什么以及如何使用该产品的细节。您的团队的目标是设想一种有价值、可用且可构建的产品。你会在这里做很多碎石工作。希望您只将所需的最少数量的故事移至描述最小可行产品发布的发布积压列表中。
  4. During discovery, you’ll discuss the specifics of who uses the product, why, and how. Your team’s goal is to envision a product that’s valuable, usable, and feasible to build. You’ll do lots of rock breaking here. Hopefully you’ll move only the smallest number of stories you need forward into a release backlog that describes a minimum viable product release.
  5. 在规划发展战略时,您将讨论风险在哪里——来自对用户喜欢和采用什么的担忧的风险,以及来自真正技术可行性问题的风险。你会以学习为中心来打破僵局,首先构建你需要的东西,然后学到最多的东西。
  6. When planning a development strategy, you’ll discuss where the risks are—risks that spring from concerns about what users will like and adopt, and risks that spring from real technical feasibility concerns. You’ll break rocks with learning in mind, building what you need to first, to learn the most.
  7. 在计划下一个开发周期时,您将拥有最后一次最好的讨论,以准确决定要构建什么,并就如何检查软件以确认其完成达成协议。这些协议中的每一个都提供了进一步分解故事的机会,其中每个故事只满足一个协议。
  8. When planning for the next development cycle, you’ll have your last best discussions to decide exactly what to build and make agreements on how you’ll check the software to confirm it’s complete. Each one of those agreements provides an opportunity to break down a story even further where each story satisfies as little as one agreement.

你可以看到,如果你试图同时进行所有这四次对话,那将是一场漫长而令人筋疲力尽的对话。需要各种各样的人来权衡不同的方面。你可能已经从我的警告和你自己过去的经验中了解到,一大群人不能有效地一起工作——至少不是所有人都同时在同一个房间里。这就是为什么我们会随着时间的推移通过大量对话逐步分解故事。

You can see that if you tried to have all four of these conversations in the same sitting, it’d be a long, grueling conversation. It’d take a wide variety of people to weigh in on different aspects. And you’ve probably gathered from my warnings and your own past experience that big groups of people don’t work effectively together—at least not all in the same room at the same time. That’s why we break stories down progressively over time with lots of conversations.

重新组装碎石

Reassembling Broken Rocks

Asteroids游戏中,您必须非常小心地射击哪些小行星,因为一旦它们破碎,您就无法将分裂的小行星重新组合在一起。但是您可以将拆分的故事重新组合在一起。

In the Asteroids game, you have to be very careful about which asteroids you shoot because you can’t put split asteroids back together once they’re broken. But you can put split stories back together.

为避免积压大量小故事,将一堆故事放在一起,然后将它们的所有标题作为项目符号列表写在一张卡片上。在你的新卡片上用一个标题总结这些标题。瞧,你有一个大故事。

To avoid a backlog filled with lots of tiny stories, take a bundle of stories that go together, and write all their titles on a single card as a bulleted list. Summarize those titles with a single title on your new card. Voilà, you’ve got one big story.

当你想到它时,这是非常棒的东西。卡片和写在上面的标题是许多无形想法的有形手柄。想法比石头或厚重的文件更具可塑性。我们有时会忘记软件开发的另一个名字是知识工作。当我们忘记这一点,转而专注于文件和流程时,它就会变成枯燥而繁琐的事情。当我与管理大量积压的、充满小故事的人一起工作时,感觉就像秘书一样可怕。

This is pretty fantastic stuff when you think about it. The card, and the title written on it, is a tangible handle to lots of intangible ideas. Ideas are a lot more malleable than rocks or heavy documents. We sometimes forget that another name for software development is knowledge work. When we forget that and instead fixate on documents and process, it turns into something dry and secretarial. And when I work with people managing huge backlogs filled with tiny stories, it feels horribly secretarial.

不要过度映射

Don’t Overdo the Mapping

我经常听到有人试图弄清楚这个故事地图的东西,说它“太多了”。当我问他们“出了什么问题?” 他们会告诉我如何创建一个非常大的整个系统图来讨论一个简单的功能。他们是对的:这太多了。所以不要那样做。

I often hear from people trying to figure out this story mapping stuff that it’s just “too much.” When I ask them “What went wrong?” they’ll tell me about creating a very large map of their whole system in order to discuss a simple feature. They’re right: that’s too much. So don’t do that.

仅映射您需要讲述您的功能故事的内容。

Map only what you need to tell a story about your feature.

例如,我曾与一家公司合作,对其协作文档编辑软件中的评论功能进行了一些更改。该团队在高层次上绘制了文档编辑,他们只使用了几张卡片。当他们到达评论区域时,他们添加了更多卡片,在一张卡片上使用大量项目符号来总结他们的产品今天所做的事情。然后他们开始讨论他们想要做出的改变,为他们正在考虑的所有细节和选项添加更多卡片。

For example, I was working with a company making some changes to the commenting feature in its collaborative document editing software. The team mapped document editing at a high level, and they only used a few cards for that. When they got to the area for commenting, they added more cards that summarized what their product did today using lots of bullets on a single card. Then they began to discuss changes they’d like to make, adding lots more cards for all the details and options they were considering.

将功能添加到现有产品时,请将功能映射到用户故事中该功能开始的位置之前,并稍微超出它的结束位置。不要映射你的整个产品。

When adding a feature into an existing product, map a little ahead of where the feature begins in your users’ story, and a little beyond where it ends. Don’t map your whole product.

请记住,故事地图支持关于用户和产品创意的对话。一个好的经验法则是:如果不需要讨论它,则不需要映射它。

Remember that story maps support conversations about your users and your product ideas. A good rule of thumb is this: if you don’t need to discuss it, you don’t need to map it.

不要为小事操心

Don’t Sweat the Small Stuff

我已经描述了整个破岩之旅,甚至告诫你在旧的 Atari 游戏中像对待小行星一样对待这些岩石,这样你就不会太快地打破它们。隐藏在所有这些策略中的是一个假设,即我们想出的很多故事都是大故事。但是,实际上,他们中的很多人都不是。在向用户交付产品或功能后,您会立即发现许多非常明显的小事情——您希望在交付之前就想到的事情,但您没有。至少我就是这样。对于那些事情,我没有机会讨论,也没有召集一个小组来进行产品发现,因为每个人都应该做这些事情。对于那些事情,我会将它们放入当前版本待办事项列表中,然后尽早与团队成员一起讨论它们,以便我们可以构建它们。错误和许多小改进也是如此。

I’ve described this whole rock-breaking journey, and even cautioned you to treat those rocks like asteroids in the old Atari game so you’re not tempted to break them down too fast. Hidden within all these strategies is the assumption that a lot of the stories we come up with are big. But, actually, a lot of them aren’t. After you deliver a product or feature to users, you’ll immediately find lots of little things that are dead obvious—things you wished you’d have thought of before shipping, but you didn’t. At least that’s what happens to me. For those things I don’t have an opportunity discussion, or pull together a group to do product discovery, because it’d be obvious to everyone they should be done. For those things, I’ll get them into a current release backlog and then as early as possible workshop them with team members so we can get them built. The same goes for bugs, and lots of little improvements.

第 18 章从你构建的一切中学习

Chapter 18. Learn from Everything You Build

如果您有传统的开发帽子,您可能会认为在构建软件时您已经完成了。但是敏捷开发和故事是为学习而构建的。在我们构建任何东西之前,我们花了很多时间来确保我们应该构建它,并就构建的内容达成一致。而且,在我们构建之后,我们会再次查看并询问是否应该构建它,以及它是否足够好。

If you’ve got a traditional development hat tightly on, you might believe you’re done when the software is built. But Agile development and stories are built for learning. We spend a lot of time before we build anything making sure we should build it, and agreeing together on what to build. And, after we build, we’ll look again and ask if should have built it, and if it’s good enough.

让我们谈谈您在构建之后必须学习的所有机会。

Let’s talk about all the opportunities you have to learn after you build.

团队审查

Review as a Team

让我们回到庆祝的部分。在开发和测试周期结束时,庆祝活动是有序的。您已经将一些想法、大量讨论、草图和挥手变成了一些诚实至善的工作软件。使用传统的需求流程会花费更长的时间。而且您和您的团队可能会对结果感到更少的所有权。

Let’s rewind to the celebrating part. At the end of a cycle of development and testing, celebration is in order. You’ve turned some ideas, lots of discussion, sketching, and hand waving into some honest-to-goodness working software. It would have taken a lot longer using a traditional requirements process. And you and your team would likely feel a lot less ownership of the result.

在击掌数次之后,是时候作为一个团队坐下来坦诚相见了看看我们取得的成就。如果我们对自己诚实,我们可能会发现一些我们可以改变的东西来改进软件。对于其中的每一件事,我们将编写另一个故事并将其添加到我们的发布待办事项列表中。我们将决定这些是我们需要立即做出的改变,还是我们可以推迟到残局时再做的改变。

After a few high-fives, it’s time to sit down as a team and take an honest look at what we’ve accomplished. If we’re being honest with ourselves, we’ll likely find some things we’d change to improve the software. For each of those things, we’ll write another story and add it to our release backlog. We’ll decide if these are changes we need to make right away, or changes we can defer ‘til later during our endgame.

在 Scrum 等流程中,这称为冲刺评审如果您是 Scrum 从业者,您可能听说过欢迎所有人参加这次评审,但我建议您做一些不同的事情。

In processes like Scrum, this is called a sprint review. If you’re a Scrum practitioner, you may have heard that everyone is welcome at this review, but I’m going to suggest you do something different.

密切合作的团队进行了最后的、最好的故事对话、就构建内容达成一致并共同构建它需要时间和安全的地方来公开讨论他们的工作。团队以外的其他人,包括业务领导,对产品的看法很重要,团队需要听取他们的意见。但这些人并没有参与建立对构建内容细节的共同理解的对话。他们没有参与制定软件构建详细计划的讨论。他们并没有与团队一起工作,因为它将所有这些讨论和协议变成了工作软件。我们需要首先评估我们是否按照我们希望的质量水平和我们计划的时间框架构建了我们设想的内容。在团队产品审查和反思中执行此操作.

The team that worked closely together, had those last, best story conversations, agreed on what to build, and worked together to build it needs time and a safe place to openly discuss their work. What others outside the team, including business leadership, think of the product is important and the team needs to hear their opinions. But those people weren’t in the conversations that built shared understanding about the details of what to build. They weren’t part of the discussions that created the detailed plans to build software. And they weren’t working alongside the team as it turned all these discussions and agreements into working software. We need to first evaluate if we’ve built what we envisioned at the quality level we hoped for and in the timeframe we planned. Do this in a team product review and reflection.

与您组织中的其他人一起审查

Review with Others in Your Organization

当团队对他们的产品进行了公正的评估后,扩大受众范围以包括组织中感兴趣的任何其他人。该小组需要了解你们作为一个团队进行的讨论以及你们所做的任何权衡。请记住,您已经翻译成可运行软件的故事很可能是从成品的更大愿景中切下的小石头。团队外的人可能希望看到成品。他们可能会指出缺少的内容,因为他们不是您决定推迟到以后的计划会议的一部分。期待那个。并帮助他们了解您刚刚构建的部分如何融入更大的计划。利益相关者产品审查中执行此操作。

When the team has given their product a fair evaluation, widen the audience to include anyone else in the organization that’s interested. This group will need some insight on the discussions you had as a team and any tradeoffs you made. Remember, the stories you’ve translated to working software are likely little rocks chipped off of a larger vision of the finished product. People outside the team may be expecting to see that finished product. They’re likely to point out what’s missing because they weren’t part of the planning sessions where you decided what to defer until later. Expect that. And help them understand how the pieces you’ve just built fit into the bigger plan. Do this in a stakeholder product review.

足够的

Enough

我很自信,当我使用我喜欢的产品时,我不会欣赏其中的所有小细节和决定。事实上,如果它工作得很好,我几乎不会注意到这个产品。我没有注意到我的移动设备是如何断开和重新建立互联网连接的。我没有注意到当我在我的任务管理软件的移动应用程序中更改某些内容的位置时,Web 版本似乎立即同步了。但这些都是重要的品质。如果他们不在,我会注意到的。你们作为一个团队一直在考虑很多细节。但是,奇怪的是,您可能不希望用户和其他人注意到它们。事实上,你可能想注意到他们没有注意到他们。

I’m confident when I use a product I like that I’m not appreciating all the little details and decisions that went into it. In fact, if it’s working really well, I hardly notice the product at all. I don’t notice how my mobile device loses and reestablishes an Internet connection. I don’t notice how when I change the position of something in the mobile app of my task management software that the web version seems to be immediately in sync. But these are important qualities. And I’d notice if they weren’t there. You as a team have been stewing in lots of details. But, oddly, you may not want users and others to notice them. In fact, you may want to notice that they don’t notice them.

当您将足够多的软件放在他们面前时,您将从组织中的利益相关者、购买您产品的客户以及将使用它的个人用户那里学到最多,他们可以清楚地看到它如何帮助他们达到以下目标之一他们的目标。

You’ll learn the most from the stakeholders in your organization, customers who buy your product, and individual users who’ll use it when you put enough software in front of them that they can clearly see how it’ll help them reach one of their goals.

对于利益相关者
For stakeholders
足够的软件可能是增加了一项对获得新客户至关重要的功能。或者足够的信息可能是关于您所了解的具有竞争力的功能必须包含的详细信息。
Enough software may be the addition of a feature critical to acquiring new customers. Or enough may be information on what you’ve learned about the details that must be in that feature to be competitive.
对于客户
For customers
足够的软件可能会增加一个功能当他们或他们的组织开始使用新软件时,这将代表他们的真正价值。
Enough software may be the addition of a feature that will represent real value for them when they or their organization begin to use the new software.
对于用户
For users
足够的软件可能是添加软件,使他们能够使用您的产品达到他们的目标之一。
Enough software may be the addition of software that allows them to reach one of their goals using your product.

如果你的破岩过程做得很好,你最终会得到很多小的、可拼砌的零件。这些部分中的每一个都让您和您的团队学到了一些东西。但是,如果你做得对,那些小部分可能不足以与其他群体相关。

If you did your rock-breaking process well, you ended up with lots of small, buildable parts. Each of those parts allowed you and your team to learn something. But, if you were doing it right, those small parts are likely not enough to be relevant to other groups.

在我看来,我把这想象成我们构建的小块软件像乐高积木一样堆积起来。我把所有这些积木都装到一个老式秤上,那种有两个平台,一侧有配重的秤。我衡量这堆越来越多的软件的是一块更大的乐高积木,它代表足够——足以让用户完成一项任务或达到一个目标;足以让客户将其视为其价值主张的一部分;足以让业务利益相关者了解它如何帮助我们的组织实现业务目标。当足够多的软件堆积起来并达到顶峰时,就该与用户一起测试该软件,与客户一起审查它,或者与业务利益相关者一起审查它。

In my mind, I picture this as small bits of software we build piling up like LEGO bricks. I load all those bricks onto an old-fashioned scale, the kind with two platforms and a counterweight on one side. What I weigh this growing pile of software against is a bigger LEGO brick that represents enough—enough to allow a user to complete a task or reach a goal; enough for customers to see it as part of their value proposition; enough for business stakeholders to see how it helps our organization reach a business goal. When enough software piles up and tips the scales, it’s time to test that software with users, review it with customers, or review it with business stakeholders.

作为一个由密切合作者组成的团队,您需要审查每个故事的结果,不仅要学习和改进您的产品,还要学习和改进您的计划方式和合作方式。当从其他群体获得反馈和学习时,要注意哪些对这些群体来说已经足够了。

You as a team of close collaborators need to review the results of every single story to learn and improve not only your product, but also the way you plan and the way you work together. When getting feedback and learning from other groups, be sensitive to what is enough for those groups.

向用户学习

Learn from Users

当我们开始时,我们可能非常自信我们正在构建正确的东西,但要保持自信,与用户一起测试工作软件很重要。

We may have been pretty confident that we were building the right things when we started, but to stay confident it’s important to test the working software with users.

请注意,我在这里说的是测试。我们不会通过玩“展示和讲述”的游戏从用户那里学到很多东西——也就是说,通过向他们展示它并让他们想象使用它并决定他们是否喜欢它。这有点像在陈列室地板上看一辆新车,并试图决定你是否喜欢驾驶它。测试您的软件将帮助用户真正评估它是否解决了他们遇到的问题。作为一个团队,我们将通过观察他们使用它来了解更多。如果您和您的团队进行了良好的故事对话,您可能会谈论用户、为什么他们会重视您正在构建的东西,以及他们会如何使用它。正是看着他们使用它,才真正验证了这些假设。

Notice that I said test here. We don’t learn much from users by playing “show and tell”—that is, by demonstrating it to them and asking them to imagine using it and decide if they’d like it. It’s a little like looking at a new car on a showroom floor and trying to decide if you’d enjoy driving it. Test-driving your software will help users really evaluate if it’s solving a problem they have. As a team, we’ll learn more by watching them use it. If you and your team were having good story conversations, you likely talked about users, why they’d value what you were building, and how they’d use it. It’s watching them use it that really validates those hypotheses.

当您拥有足够多的软件来允许用户完成对他们有意义的事情时,就该进行测试了。您可能不是在测试全新的东西。您可能对产品已有的功能进行了更改或增强。花时间与用户一起观察他们使用你的软件做真实的工作。

When you’ve got enough software to allow users to accomplish something meaningful to them, it’s time to test. You may not be testing something completely new. You may have made changes or enhancements to something your product already does. Spend time with users to observe them using your software doing realistic work.

从向用户发布中学习

Learn from Release to Users

您构建了少量软件并作为一个团队审查了它的每一部分。您定期与组织内部的利益相关者、将购买或采用您的产品的客户以及将使用它的用户一起审查它。但是,如果您还记得本书的开头,它并不是我们真正想要的软件——它是我们在软件交付并投入使用后得到的结果。

You’ve built small amounts of software and reviewed every bit of it as a team. You’ve periodically reviewed it with stakeholders insider your organization, and with customers who’ll buy or adopt your product, and with users who’ll use it. But, if you remember where this book started, it’s not the software we really wanted—it’s the outcomes we get after the software is delivered and put into use.

当您觉得自己已经构建了足够多的内容并有信心获得这些结果时,就该将软件发布到世界上了。

When you feel like you’ve built enough that you’re confident you’ll get those outcomes, then it’s time to release the software into the world.

我又想象了一个秤,上面堆满了我与用户一起测试过的软件块,反复改进,现在我有信心可以发布了。我将平衡那堆越来越大的砖块和另一块更大的砖块,这块砖块也代表足够——足以发布并在目标受众中取得成功。当我受够了,是时候释放了。

I picture one more scale that’s piling up with bricks of software that I’ve tested with users, iteratively improved, and I’m now confident could be released. I’ll balance that growing pile against yet another, larger brick that also represents enough—enough to release and be successful with its target audience. When I’ve got enough, it’s time to release.

您需要计划从每个版本中学习。请不要发布软件并坐等您的客户和用户抱怨。这些抱怨是结果。但他们往往滞后于他们的真实感受以及您的产品实际性能的指标。对于每个版本,作为一个团队讨论你将如何衡量或观察你的产品的用户,看看你是否真的得到了你预期的结果。讨论并决定你将如何:

You’ll need to plan to learn from each release. Please don’t release software and sit around waiting for your customers and users to complain. Those complaints are outcomes. But they’re often lagging indicators of how they really feel and how well your product will really do. For each release, discuss as a team how you’ll measure or observe the users of your product to see if you really got the outcomes you expected. Discuss and decide how you’ll:

  • 在您的产品中构建指标,使您可以跟踪新功能的使用情况
  • Build metrics into your product that allow you to track usage of new features
  • 安排时间观察用户使用新版本
  • Schedule time to observe users as they use the new release

作为一个团队,定期讨论你们学到了什么,然后采纳你们的想法进行改进并撰写更多故事。有些您会认为非常重要,可以立即实施。以及其他你会看到的机会,可以添加到你的机会积压中。

As a team, routinely discuss what you’ve learned, and then take your ideas for improvement and write more stories. Some you’ll see as important enough to implement right away. And others you’ll see as opportunities to add to your opportunity backlog.

按计划取得成果

Outcomes on a Schedule

有一些公司和一些软件允许我们在有足够的时候发布。但是对于大量的公司和产品,如果不是大多数,我们需要按计划发布。如果我们一直在有效地使用我们的开发策略,我们就已经在我们早期的开场故事中奠定了基础,使用中期故事构建了产品,并且在发布时,我们正在播放我们的终局故事。

There are some companies and some software that allow us to release whenever we have enough. But for a great number of companies and products, if not most of them, we need to release on a schedule. If we’ve been using our development strategy effectively, we’ve laid down a foundation in our early opening-game stories, built up the product using midgame stories, and when it comes time to release, we’re playing our endgame stories.

现在我需要提醒你一些关于软件开发的更多真相。

Now I need to remind you of a few more truths about software development.

软件永远不会真正完成。

Software is never really done.

您将在较短的开发周期内为您的团队完成的每个故事完成软件实施。但是您可能不会完成您在开发开始时想象的每个故事,或者在您学习每个周期时进行识别。但是,如果您使用了有效的开发策略,则该软件在发布时会尽可能好。

You’ll finish implementing the software for each story your team takes on during a short development cycle. But you likely won’t finish every story you imagine at the outset of development, or identify as you learn each cycle. If you’ve used an effective development strategy, however, the software will be as good as it possibly can be at the time it’s released.

结果永远没有保险。

Outcomes are never insured.

尽管你已经做了所有的工作来验证你正在构建正确的东西,但使用你的产品的人通常不会像预期的那样行事。计划学习每个版本。计划根据您所学的内容进行更改。

In spite of all the work you’ve done to validate that you’re building the right things, people using your product often don’t behave as predicted. Plan to learn with each release. Plan to make changes based on what you’ve learned.

发布后所做的改进是最有价值的。

Improvements made after release are the most valuable.

当用户开始频繁采用和使用您的软件时,您会观察到那些不可预知的事情,从而产生最深刻的洞察力。如果您计划时间来真正衡量和观察结果,您将得到真正热爱您的产品和对您的组织真正有价值的产品的人的回报。

It’s those unpredictable things that you’ll observe when users begin to adopt and use your software frequently that yield the most insight. If you plan for time to really measure and observe outcomes, you’ll be rewarded with people who really love your product and a product that’s really valuable for your organization.

使用地图评估发布准备情况

Use a Map to Evaluate Release Readiness

您将逐个故事地完成您的产品发布故事。当您接近您承诺的交付日期时——承诺的交付日期总是存在的——对于每个主要用户活动都会问,“如果我们必须立即发货,我们会给自己打几分?” 如果你像我的孩子在学校那样使用字母等级,你最终会得到你的产品的成绩单。

You’ll complete your product release story by story. As you draw near the date you promised to deliver—and there’s always a promised delivery date—for each major user activity ask, “If we had to ship right now, what grade would we give ourselves?” If you use letter grades like my kids get in school, you’ll end up with a report card for your product.

例如,如果您在承诺的发布日期前几周查看了具有五项主要活动的产品或功能,并看到了A、A–、B+、D、B+的成绩单,您可能希望将剩余的几周和关注用户工作流程中当前评分为D的部分。如果最后你用A s 和B s 发布,那很好。当然,全A会更好,但按时完成可能更重要。

For example, if you looked at a product or feature with five major activities a few weeks before its promised release date, and saw a report card of A, A–, B+, D, B+, you might want to take the remaining weeks and focus on the part in the user’s workflow that’s currently graded a D. If in the end you release with A s and B s, that’s pretty good. Of course, straight A s would be better, but getting it out on time may be more important.

没有标题的图片

当您临近产品发布日期时,一起评估发布准备情况。我向你保证,每个人都想知道。

As you draw near the release date of your product, work together to assess release readiness. I promise you, everyone wants to know.

这本书快完成了。如果您已经读到这里,您可能对其发布准备情况有一些看法。你可以回到目录并在每一章上写下你的字母等级。拍一张智能手机照片并发送给我。我很想看看。

This book is almost done. If you’ve read this far, you may have some opinions about its release readiness. You could go back to the table of contents and write your letter grade on each chapter. Take a smartphone photo and send it to me. I’d love to see it.




[ 16 ]这种过程改进讨论通常称为回顾,并且有很多很好的方法来执行回顾。如果您想查看更全面的回顾方法秘诀,请尝试Esther Derby 和 Diana Larsen(Pragmatic)合着的《敏捷回顾》一书。

[16] This process improvement discussion is commonly called a retrospective, and there are lots of great approaches to performing one. If you’d like to look at a more comprehensive recipe of retrospective approaches, try the book Agile Retrospectives by Esther Derby and Diana Larsen (Pragmatic).

结束,还是它?

The End, or Is It?

就像一个好的软件产品一样,这本书还没有真正完成。整本书中有很多我遇到的人提供的很好的例子,他们告诉我他们在故事和故事地图方面所做的很酷的事情。我的硬盘上还有很多故事,我没有时间将它们提炼并收录到书中,这让我很难过。

Just like a good software product, this book isn’t really done. Throughout the book are lots of great examples contributed by people I’ve met who tell me about the cool things they’re doing with stories and story mapping. I’ve got a lot more stories on my hard drive, too, and it’s killing me that I don’t have time to get them refined and included in the book.

关于故事和故事地图,我还可以讨论更多细节。而且我敢肯定,关于在您自己的上下文中使用故事,您还有一些悬而未决的问题。当我接近本书的结尾时,我也担心这一点。

There are also a lot more details I could discuss about stories and story maps. And I’m sure you’ve got unanswered questions about using stories in your own context. As I reach the close of this book, I worry about that, too.

作为一名开发人员、UI 设计师和产品经理,我可以告诉你,我很少对产品发布感到高兴。那是因为那时我才知道所有我无法包括的东西,以及所有可以通过更多时间润色而变得更好的小东西。如果你真的关心你正在构建的东西,我希望你也会有这种感觉。

As someone who’s been a developer, a UI designer, and a product manager, I can tell you I’ve rarely been happy at product release. And that’s because it’s then that I know about all the things I couldn’t include, and about all the little things that could be better with just a bit more time to polish. If you really care about what you’re building, I expect you’ll feel that way as well.

我将重复我之前在第 4 章中使用的达芬奇语录:

I’ll repeat the da Vinci quote I used earlier in Chapter 4:

伟大的艺术永远不会完成,只会被抛弃。

Great art is never finished, only abandoned.

我不会说这本书是伟大的艺术。但我会说,当有更多的事情可以做时,我已经放弃了它。我会把更多的事情留给你,当你发现自己更好的合作方式来创造伟大的产品时,希望能收到你的来信。

I’ll stop short of saying this book is great art. But I will say I’ve abandoned it when there’s more that could be done. I’ll leave that more to you, and expect to hear from you when you’ve discovered your own better ways for working together to create great products.

致谢

Acknowledgments

这是本书中最难写的部分之一。在我的整个职业生涯中,我很幸运能够得到很多人的支持。我已经并将继续从我遇到和共事的每个人那里得到如此多的鼓励。所以,让我害怕的是,一旦我开始感谢别人,我就会把某人排除在外。如果我把你排除在外,我很抱歉,而且我怀疑你的公司很好。

This was one of the hardest parts of this book to write. I’ve been blessed enough to enjoy the support of a huge number of people throughout my career. I have and continue to receive so much encouragement from everyone I meet and work with. So, what scares me is that as soon as I start thanking people, I’m going to leave someone out. If I’ve left you out, I am very sorry, and I suspect you’re in good company.

而且,另一件事是我很确定我没有任何原创想法。我听说有人争辩说没有原创的想法了。但具体对我而言,我所知道的一切都是从过去二十年与我共事的智者那里学到的。从这些有见地的朋友和同龄人那里,我学习并应用了新的想法和实践。通过与他们长时间的讨论,我学会了解释和深刻理解我在练习手艺时的经历。似乎很难将本书中的任何想法归功于本书,因为我知道大多数想法都是从别人那里借来的,或者只是从别人那里偷来的。

And, another thing is that I’m pretty sure I don’t have any original ideas. I’ve heard it argued that there are no original ideas left. But for me specifically, everything I know I’ve learned from the wise people I’ve worked with over the past two decades. From these insightful friends and peers I’ve learned and applied new ideas and practices. Through long discussions with them, I’ve learned to interpret and deeply understand the experiences I’ve had when practicing my craft. It seems hard to take credit for any of the ideas in this book since I know most were borrowed or simply stolen from others.

每当我确实有了我认为是原创的想法时,我就会想起隐忘症。这是一个有趣的词,适用于乔治·哈里森 (George Harrison) 和翁贝托·埃科 (Umberto Eco) 等知名人士所犯的意外剽窃。当被遗忘的记忆重新出现而没有被识别为记忆时,就会出现隐忘症。crytomnesiac 相信他们刚刚想出的好主意是新的和原创的,而不是对他们读过、听过或以其他方式经历过的事情的遗忘记忆。我在下面感谢的人很可能是我无意中窃取的许多人。

Whenever I do have what I believe to be an original idea, I’m reminded of cryptomnesia. It’s a fun word that applies to the accidental plagiarism that reputable people like George Harrison and Umberto Eco are guilty of. Cryptomnesia occurs when a forgotten memory returns without it being recognized as a memory. The crytomnesiac believes the great idea they’ve just come up with is new and original, and not the forgotten memory of something they’ve read, heard, or otherwise experienced. The people I’m thanking below are quite likely many of the people I’ve unintentionally stolen from.

因此,在序言中,我将开始:

So with that preamble, I’ll get started:

我几乎放弃了写书。在过去的十年里,当我试图写作时,我遇到了一个真正的问题。我似乎可以写短文或发表演讲,但一旦我尝试写超过几千字的东西时,事情就跑偏了。我可以最好地将我的书写作描述为动物标本剥制术。那就是我会拿走一些活生生的美丽东西,然后杀死它并填满它。我所能希望的最好的就是它会栩栩如生。Peter Economy 让我摆脱了那个循环。正是他多年的写作经验和他始终积极和支持的态度帮助我找到了一个行之有效的书面声音。我很感谢彼得。如果你正在努力写一本书,你应该打电话给彼得。

I’d practically given up on writing a book. I’ve had a real problem when I was trying to write over the past ten years. I seemed to be able to write short articles, or give a talk, but as soon as I tried to write anything longer than a couple thousand words, things went sideways. I can best describe my book writing as taxidermy. That is I’d take something living and beautiful and then kill it and stuff it. The best I could hope for is that it would be lifelike. Peter Economy broke me out of that cycle. It was his years of experience writing and his always positive and supportive attitude that helped me find a written voice that worked. I’m grateful to Peter. If you’re struggling to get a book written, you should call Peter.

Martin Fowler、Alan Cooper 和 Marty Cagan 都是我心目中的英雄。我很高兴与他们所有人会面、一起工作并享受与他们所有人的长时间对话。他们的想法影响了我的整个职业生涯。三人中有两人认为在书中加入三个前言是个坏主意,但我很高兴我坚持了下来,他们也同意了。他们代表了工程、用户体验和产品思维的声音,我认为这些对于创造成功的产品至关重要。我认为至关重要的是,您,读者,能听到他们每个人的意见。

Martin Fowler, Alan Cooper, and Marty Cagan are all heroes of mine. I’ve had the pleasure of meeting with, working with, and enjoying long conversations with all of them. Their thinking has influenced mine throughout my career. Two of the three thought it was a bad idea to have three forewords in the book, but I’m glad I insisted, and they agreed. They represent the voices of engineering, user experience, and product thinking that I see as critical to creating successful products. I think it was critical that you, the reader, heard from each of them.

Alistair Cockburn 十多年来一直是我的朋友和导师。我很确定,我认为我的伟大想法中的大部分都是直接从 Alistair 以及我与他的长时间对话中窃取的。把我贴在墙上和桌面上的故事卡片模型称为“故事地图”,来自其中一次对话。当我试图向 Alistair 解释它是什么时,我记得我说过“这只是一张故事地图”。“那么,你为什么不那样称呼它呢?”阿利斯泰尔说。那而不是我一直在折腾的其他愚蠢的名字。

Alistair Cockburn has been a friend and mentor of mine for over a decade. I’m quite certain that much of what I believe are my great ideas were stolen directly from Alistair and my long conversations with him. Calling the model of story cards I put on walls and tabletops a “story map” came from one of these conversations. As I was trying to explain to Alistair what it was I recall saying “it’s just a map of stories.” “Then, why don’t you call it that” Alistair said. That instead of the other silly names I’d been tossing around.

多年前我开始用卡片讲故事和建立产品待办事项列表的做法来自于我从朋友拉里·康斯坦丁那里学到的混蛋做法。如果没有直接向 Larry 学习的机会,故事映射的实践以及我对用户体验的看法将永远不会出现。

What I started doing with cards years ago to tell stories and build product backlogs came from bastardizing practices I learned from my friend Larry Constantine. The practice of story mapping and how I think of user experience would never have come about without the opportunity to learn directly from Larry.

大卫·哈斯曼 (David Hussman) 多年来一直是我明智的朋友、支持者和志趣相投的人。看着大卫讲故事并得到他的鼓励,这帮助我找到了今天的声音。在他们被称为故事地图之前,大卫正在创建故事地图。

David Hussman has been my wise friend, supporter, and a kindred spirit to me for years now. It’s watching David tell stories and receiving his encouragement that’s helped me find the voice I have today. David was creating story maps before they were called that.

而且,如果没有 Tom 和 Mary Poppendieck 的支持,我永远不可能完成一本书。尤其是汤姆,他读了我过去十年来最糟糕的一些动物标本剥制术,并且仍然提供了鼓励的话。几个月前,他拒绝离开我的房子,直到我把我的终稿寄给 O'Reilly。如果他没有,我会一直摆弄这本书,永远不会认为它足够好。

And, I’d never have gotten a book completed without the support of Tom and Mary Poppendieck. Tom in particular has read some of my worst taxidermy over the past decade, and still offered words of encouragement. A few months ago, he refused to leave my house until I sent my final draft to O’Reilly. If he hadn’t, I’d have kept twiddling with the book, never considering it good enough.

一路上作为支持者和良好建议来源脱颖而出的其他朋友包括 Zhon 和 Kay Johansen、Aaron Sanders 和 Erica Young、Jonathan House、Nate Jones 和 Christine DelPrete。

Other friends that stand out as supporters and sources of good advice along the way include Zhon and Kay Johansen, Aaron Sanders and Erica Young, Jonathan House, Nate Jones, and Christine DelPrete.

特别感谢 Gary Levitt、Globo.com 的所有人员、Liquidnet 的 Eric Wright 以及我在 Workiva 的所有朋友,感谢他们让我在本书的第一章讲述他们的故事。

Special thanks to Gary Levitt, all the people at Globo.com, Eric Wright from Liquidnet, and all my friends at Workiva for letting me tell their stories in the first chapters of this book.

多年来,我无数次被想告诉我他们如何使用故事地图或应用我给他们的建议的故事的人拦住。我内疚的秘密是,我从他们身上学到的比我认为他们从我身上学到的要多。我很高兴能从其中一小部分人那里为本书做出贡献。特别感谢那些可以在短时间内为我做出贡献的人:Josh Seiden、Chris Shinkle、Sherif Mansour、Ben Crothers、Michael Vath、Martina Luenzman、Andrea Schmieden、Ceedee Doyle、Erin Beierwaltes、Aaron White、Mat Cropper、Chris Gansen和杰森·库内什、里克·库西克、尼古拉·亚当斯和史蒂夫·巴雷特。

Countless times over the years I’ve been stopped by people who wanted to tell me their stories about how they’d used story mapping or applied a piece of advice I’d given them. My guilty secret is that I learn more from them than I think they get from me. I was happy to get contributions from just a fraction of them for this book. Special thanks to those that could get me a contribution given very short notice: Josh Seiden, Chris Shinkle, Sherif Mansour, Ben Crothers, Michael Vath, Martina Luenzman, Andrea Schmieden, Ceedee Doyle, Erin Beierwaltes, Aaron White, Mat Cropper, Chris Gansen and Jason Kunesh, Rick Cusick, Nicola Adams, and Steve Barrett.

我与一大群人交谈并从中了解到我根本没有给足够的时间来满足我不合理的最后期限。这些人包括:Ahmad Fahmy、Tobias Hildenbrand、Courtney Hemphill、Samuel Bowles、Rowan Bunning、Scout Addis、Holly Bielawa 和 Jabe Bloom。对于这些人和所有阅读本文的人,我仍然想要你的故事。也许我会发布这本书的特别导演剪辑版,其中包括所有这些已删除的场景。

There’s a big group of people that I spoke with and learned from that I simply didn’t give enough time to meet my unreasonable deadline. These people include: Ahmad Fahmy, Tobias Hildenbrand, Courtney Hemphill, Samuel Bowles, Rowan Bunning, Scout Addis, Holly Bielawa, and Jabe Bloom. To these people and all of you reading this, I still want your stories. Perhaps I’ll release a special directors cut of the book that includes all these deleted scenes.

在完成本书的最后阶段,我收到了来自 Barry O'Reilly、Todd Webb 以及在最后一刻来自 Petra Wille 的宝贵详细评论。他们所有详细的评论帮助我消除了书中的粗糙边缘。

In the final stretch of getting this book done, I received valuable detailed reviews from Barry O’Reilly, Todd Webb, and at the last minute from Petra Wille. All of their detailed comments helped me smooth out the rough edges in the book.

最后,感谢 Mary Treseler 和 O'Reilly 的制作团队容忍我的延误和奇怪的日程安排,并陪我到最后。

Finally, thanks to Mary Treseler and the production team at O’Reilly for putting up with my delays and funky schedule, and sticking with me to the bitter end.

参考

References

Adlin、Tamara 和 John Pruitt。角色基本生命周期:角色构建和使用指南。伯灵顿:摩根考夫曼,2010 年。

Adlin, Tamara, and John Pruitt. The Essential Persona Lifecycle: Your Guide to Building and Using Personas. Burlington: Morgan Kaufmann, 2010.

阿季奇,戈伊科。影响图:对软件产品和项目产生重大影响。英国萨里:发人深省,2012 年。

Adzic, Gojko. Impact Mapping: Making a Big Impact with Software Products and Projects. Surrey, UK: Provoking Thoughts, 2012.

--. 实例说明:成功的团队如何交付正确的软件。庇护岛:曼宁出版社,2011 年。

--. Specification by Example: How Successful Teams Deliver the Right Software. Shelter Island: Manning Publications, 2011.

阿米蒂奇,约翰。“敏捷方法是否适合设计”,Interactions,第 11 卷,第 1 期,2004 年 1 月至 2 月。http://dl.acm.org/citation.cfm?id= 962352

Armitage, John. “Are Agile Methods Good for Design,” Interactions, Volume 11, Issue 1, January-February, 2004. http://dl.acm.org/citation.cfm?id=962352.

贝克,肯特。 极限编程解释:拥抱变化。纽约:Addison-Wesley Professional,1999 年。

Beck, Kent. Extreme Programming Explained: Embrace Change. New York: Addison-Wesley Professional, 1999.

贝克、肯特和迈克尔·福勒。规划极限编程。纽约:Addison-Wesley Professional,2000 年。

Beck, Kent, and Michael Fowler. Planning Extreme Programming. New York: Addison-Wesley Professional, 2000.

卡根,马蒂。启发:如何创造客户喜爱的产品。桑尼维尔:SVPG 出版社,2008 年。

Cagan, Marty. Inspired: How to Create Products Customers Love. Sunnyvale: SVPG Press, 2008.

程,凯文。明白我的意思:如何使用漫画来交流思想。布鲁克林:罗森菲尔德媒体有限责任公司,2012 年。

Cheng, Kevin. See What I Mean: How to Use Comics to Communicate Ideas. Brooklyn: Rosenfeld Media, LLC, 2012.

科伯恩,阿利斯泰尔。敏捷软件开发。纽约:Addison-Wesley Professional,2001 年。

Cockburn, Alistair. Agile Software Development. New York: Addison-Wesley Professional, 2001.

--. 编写有效的用例。纽约:Addison-Wesley Professional,2000 年。

--. Writing Effective Use Cases. New York: Addison-Wesley Professional, 2000.

科恩,迈克。应用的用户故事:用于敏捷软件开发。纽约:Addison-Wesley Professional,2004 年。

Cohn, Mike. User Stories Applied: For Agile Software Development. New York: Addison-Wesley Professional, 2004.

Constantine、Larry L. 和 Lucy AD Lockwood。使用软件:以使用为中心的设计模型和方法实用指南。纽约:Addison-Wesley Professional,1999 年。

Constantine, Larry L., and Lucy A.D. Lockwood. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. New York: Addison-Wesley Professional, 1999.

库珀,艾伦。囚犯正在经营庇护所:为什么高科技产品让我们发疯以及如何恢复理智。印第安纳波利斯:Sams – Pearson Education,2004 年。

Cooper, Alan. The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. Indianapolis: Sams – Pearson Education, 2004.

戈瑟夫,杰夫。精益用户体验:应用精益原则改善用户体验。塞瓦斯托波尔:O'Reilly Media,2013 年。

Gothelf, Jeff. Lean UX: Applying Lean Principles to Improve User Experience. Sebastopol: O’Reilly Media, 2013.

Jeffries、Ron、Ann Anderson 和 Chet Hendrickson。安装了极限编程。纽约:Addison-Wesley Professional,2007 年。

Jeffries, Ron, Ann Anderson, and Chet Hendrickson. Extreme Programming Installed. New York: Addison-Wesley Professional, 2007.

克莱因,劳拉。精益创业的用户体验:更快、更智能的用户体验研究和设计。塞瓦斯托波尔:O'Reilly Media,2013 年。

Klein, Laura. UX for Lean Startups: Faster, Smarter User Experience Research and Design. Sebastopol: O’Reilly Media, 2013.

里斯,埃里克。精益创业:当今的企业家如何利用持续创新来创造极其成功的企业。纽约:Crown Business,2011 年。

Ries, Eric. The Lean Startup: How Today’s Entepreneurs Use Continuous Innovation to Create Radically Successful Businesses. New York: Crown Business, 2011.

是的,德西瑞。“适应以用户为中心的敏捷设计的可用性调查,”可用性研究杂志,卷。2,第 3 期,2007 年 5 月。http://www.upassoc.org/upa_publications/jus/2007may/agile-ucd.html

Sy, Desiree. “Adapting Usability Investigations for Agile User-Centered Design,” Journal of Usability Studies, Vol. 2, Issue 3, May 2007. http://www.upassoc.org/upa_publications/jus/2007may/agile-ucd.html.

汤姆德马科等人。肾上腺素瘾君子和模板僵尸:了解项目行为模式。纽约:多塞特宫,2008 年。

Tom Demarco et al. Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior. New York: Dorset House, 2008.

耶茨,仁。蛋糕残骸:当专业蛋糕搞笑地出错时。堪萨斯城:Andrews McMeel 出版社,2009 年。

Yates, Jen. Cake Wrecks: When Professional Cakes Go Hilariously Wrong. Kansas City: Andrews McMeel Publishing, 2009.

指数

Index

一种

A

验收标准,3.确认
acceptance criteria, 3. Confirmation
同意,在交付过程中深入了解每个故事的细节
细化、定义和构建章节,拆分和精简
agreeing on, Dive into the Details of Each Story During Delivery
for Refine, Define, and Build chapter, Split and Thin
活动,4. 提炼你的地图来制作主干
activities, 4. Distill Your Map to Make a Backbone
在积压工作中确定优先级,地图只是一个开始
prioritizing in the backlog, The Map Is Just the Beginning
Adams、Nicola、Sprint 还是 Iteration Planning?
Adams, Nicola, Sprint or Iteration Planning?
敏捷开发,大局观
Agile development, The Big Picture
从你构建的一切中学习,Build to Learn
Rock Breakers产品负责人
澳大利亚珀斯的 RAC Insurance,Sprint 还是 Iteration Planning?
Scrum 流程,在交付过程中深入了解每个故事的细节
故事映射和“A”字
learning from everything you build, Build to Learn
product owner, Rock Breakers
RAC Insurance in Perth, Australia, Sprint or Iteration Planning?
Scrum process, Dive into the Details of Each Story During Delivery
story mapping and, The “A” Word
假设,新的 MVP 根本不是产品!
assumptions, The New MVP Isn’t a Product at All!
具有排练映射、故事映射和机会的挑战
对话,真正谈论什么的清单
命名您的风险假设,命名您的风险假设
运行测试后重新思考,重新思考你的解决方案和你的假设
challenging with rehearsal mapping, Story Mapping and Opportunities
conversations about, A Checklist of What to Really Talk About
naming your risky assumptions, Name Your Risky Assumptions
rethinking after running your test, Rethink Your Solution and Your Assumptions
小行星视频游戏,故事实际上就像小行星
Asteroids video game, Stories Are Actually Like Asteroids
Atlassian,我们需要一张更大的卡片
Atlassian, We’re Gonna Need a Bigger Card

B

BA(见业务分析师)
BA (see business analysts)
主干(故事地图),映射帮助大团体建立共同理解
backbone (story map), Mapping Helps Big Groups Build Shared Understanding
提炼你的地图以制作,4. 提炼你的地图以制作主干
distilling your map to make, 4. Distill Your Map to Make a Backbone
backlog,Gary 和扁平化 Backlog 的悲剧1. 卡片
backlog, Gary and the Tragedy of the Flat Backlog, 1. Card
平面积压陷阱,映射帮助大团队建立共识
flat backlog trap, Mapping Helps Big Groups Build Shared Understanding
积压整理,在交付过程中深入了解每个故事的细节
backlog grooming, Dive into the Details of Each Story During Delivery
积压细化,在交付过程中深入了解每个故事的细节
backlog refinement, Dive into the Details of Each Story During Delivery
糟糕的需求,Kent 颠覆性的简单想法为学习而构建
bad requirements, Kent’s Disruptively Simple Idea, Build to Learn
Beck, Kent,“A”字Kent 颠覆性的简单想法并不总是软件
Beck, Kent, The “A” Word, Kent’s Disruptively Simple Idea, It’s Not Always Software
测试版客户,构建学习
beta customers, Build to Learn
Blank, Steve,经过验证的简短学习循环
Blank, Steve, Short Validated Learning Loops
将软件分解成更小的部分,分解大蛋糕
breaking software down into smaller parts, Breaking Down a Big Cake
预算,开发时间预算,管理您的预算
budget, time budget for development, Manage Your Budget
构建-测量-学习周期、经过验证的学习较短的经过验证的学习循环重新思考您的解决方案和您的假设
build-measure-learn cycle, Validated Learning, Short Validated Learning Loops, Rethink Your Solution and Your Assumptions
构建软件
building software
建,少建
为学习而建造,为学习而建造,为学习建造
在构建过程中继续对话,在构建过程中保持对话
迭代构建直到产生 MVP,Iterate Until Viable
Learn from everything you build, Learn from Everything You Build使用地图评估发布准备情况
计划建造更少,分解一个大蛋糕4. 最小化和计划
planning to build piece by piece,计划逐个建造
错误的方式,如何以错误的方式去做
building less, Build Less
building to learn, Build to Learn, Build to Learn
continuing conversation as you build, Keep Talking as You Build
iterative builds until MVP is produced, Iterate Until Viable
learning from everything you build, Learn from Everything You BuildUse a Map to Evaluate Release Readiness
planning to build less, Breaking Down a Big Cake, 4. Minimize and Plan
planning to build piece by piece, Plan to Build Piece by Piece
the wrong way, How to Do It the Wrong Way
业务分析师,不同的人,不同的对话
business analysts, Different People, Different Conversations
在需求收集角色中,产品负责人作为生产者
在三个朋友中,三个朋友
RAC Insurance 的 Nicola Adams,Sprint 还是 Iteration Planning?
in requirements gathering role, Product Owner as Producer
in three amigos, The Three Amigos
Nicola Adams at RAC Insurance, Sprint or Iteration Planning?
商业模式、画布方法、深入挖掘、丢弃或思考
business models, canvas approach to, Dig Deeper, Trash It, or Think About It
商业价值,按优先顺序排列故事,优先顺序的秘诀
business value, prioritizing stories by, The secret to prioritization

C

C

Cagan、Marty、经过验证的学习有价值-可用-可行深入挖掘、丢弃或思考
Cagan, Marty, Validated Learning, Valuable-Usable-Feasible, Dig Deeper, Trash It, or Think About It
画布方法来评估机会、深入挖掘、丢弃它或思考它
canvas approach to sizing up opportunities, Dig Deeper, Trash It, or Think About It
卡片对话确认流程,切割和抛光
card-conversation-confirmation flow, Cutting and Polishing
纸板,建立共识
Cardboard, Building Shared Understanding
cards
的内容,并非全部在卡上-跟踪
建立共同的理解,建立共同的理解
不同的团队角色,不同的对话,不同的人,不同的对话
散热器和冰箱,散热器和冰箱
记住,记住
跟踪大量信息,我们需要一张更大的卡片
使用工具,这不是该工具的用途
故事卡、散热器和冰箱上的真实情况
在1. 卡片上写下所需的产品功能
contents of, It’s Not All on the CardTracking
building shared understanding, Building Shared Understanding
different team roles, different conversations, Different People, Different Conversations
radiators and ice boxes, Radiators and Ice Boxes
remembering, Remembering
tracking huge amounts of information, We’re Gonna Need a Bigger Card
using tools, That’s Not What That Tool Is For
what’s really on story cards, Radiators and Ice Boxes
writing desired product features on, 1. Card
改变世界,谈论正确的事情
changing the world, Talking About the Right Thing
选择器,少构建
choosers, Build Less
客户-供应商反模式,三个朋友
client-vendor anti-pattern, The Three Amigos
需求收集角色的业务分析师,产品负责人作为生产者
business analyst in requirements gathering role, Product Owner as Producer
指导团队使用用户故事映射,地图只是一个开始
coach for team use of user story mapping, The Map Is Just the Beginning
Cockburn、Alistair,我只是更注重细节,散热器和冰箱, Build to Learn
Cockburn, Alistair, I’m Just More Detail-Oriented, Radiators and Ice Boxes, Build to Learn
代码质量,检查你的工作结果
code quality, Inspect the Results of Your Work
confirmation, 3. Confirmation , Dive into the details of each story during delivery ,切割和打磨
confirmation, 3. Confirmation, Dive into the Details of Each Story During Delivery, Cutting and Polishing
Confluence,我们需要一张更大的卡片
Confluence, We’re Gonna Need a Bigger Card
Connextra,Connextra 的炫酷模板
Connextra, Connextra’s Cool Template
对话,2.对话
conversation, 2. Conversation
关于机会,就机会进行对话
真正谈论什么的清单,真正谈论什么的清单
在构建时继续,在构建时继续说话
不同的角色,不同的对话,不同的人,不同的对话
在交付过程中深入了解故事细节,在交付过程中深入了解每个故事的细节
使用工具记录,记住
having best last conversations, Cards, Conversation, 更多卡片, 更多对话...
包括太多人,人群不合作
在讨论中保持有价值、可用和可行,三个朋友
负责所有故事对话的产品负责人,Rock Breakers
分解故事的工具,Stories Are Like Rocks
使用发布后评估产品使用,发布并继续评估
使用故事模板开始,Connextra 的酷模板
文字与图片,文字与图片
about opportunities, Have Conversations About Opportunities
checklist of what to really talk about, A Checklist of What to Really Talk About
continuing while building, Keep Talking as You Build
different roles, different conversations for, Different People, Different Conversations
diving into story details during delivery, Dive into the Details of Each Story During Delivery
documenting using tools, Remembering
having best last conversations, Cards, Conversation, More Cards, More Conversations…
including too many people, Crowds Don’t Collaborate
keeping valuable, usable, and feasible in discussions, The Three Amigos
product owner responsible for all story conversations, Rock Breakers
tool for breaking down stories, Stories Are Like Rocks
using after release to evaluate product use, Release and Keep Evaluating
using using story template to start, Connextra’s Cool Template
words and pictures in, Words and Pictures
Cs、Ron Jeffries 和 3 Cs切割和抛光
Cs, Ron Jeffries and the 3 Cs, Cutting and Polishing
卡片,1.卡片
确认,3.确认
对话,2.对话
cards, 1. Card
confirmation, 3. Confirmation
conversation, 2. Conversation
客户拦截,通过与客户和用户一起运行测试来衡量
customer intercepts, Measure by Running Your Test with Customers and Users
顾客
customers
对话,真正谈论什么的清单
描述您的客户,描述您的客户和用户
足够的软件,足够
Evaluating built software with,与用户和客户一起评估
理解,2. 理解客户和用户发现活动、讨论和工件
conversations about, A Checklist of What to Really Talk About
describing your customers, Describe Your Customers and Users
enough software for, Enough
evaluating built software with, Evaluate with Users and Customers
understanding, 2. Understand Customers and Users, Discovery Activities, Discussions, and Artifacts

D

达芬奇,莱昂纳多,达芬奇会做什么?
da Vinci, Leonardo, What Would da Vinci Do?
故事卡、散热器和冰箱上的日期
dates on story cards, Radiators and Ice Boxes
分解,讲述用户的故事
decomposition, Tell Your Users’ Stories
定义、同理心、专注、构思、原型、测试
defining, Empathize, Focus, Ideate, Prototype, Test
送货
delivery
深入了解每个故事的细节,在交付过程中深入了解每个故事的细节
在利益相关者产品审查中审查,与您组织中的其他人一起审查
diving into details of each story, Dive into the Details of Each Story During Delivery
reviewing in stakeholder product review, Review with Others in Your Organization
DeMarco、汤姆、模板僵尸和扫雪机
DeMarco, Tom, Template Zombies and the Snowplow
对故事卡、散热器和冰箱的依赖
dependencies on story cards, Radiators and Ice Boxes
故事描述,Connextra 的炫酷模板
descriptions of stories, Connextra’s Cool Template
故事卡、暖气片和冰箱的说明
descriptions on story cards, Radiators and Ice Boxes
由Rock Breakers委员会设计
design by committee, Rock Breakers
由社区设计,Rock Breakers
design by community, Rock Breakers
设计过程
design processes
从精益创业思维转变为精益创业思维如何改变产品设计
搞砸了,如何搞砸一件好事
传统的、大缺陷的、经过验证的短学习循环
changes to, from Lean Startup thinking, How Lean Startup Thinking Changes Product Design
messing up, How to Mess Up a Good Thing
traditional, big flaw in, Short Validated Learning Loops
设计工作室,文字和图片
Design Studio, Words and pictures
食谱,文字和图片
recipe for, Words and pictures
设计思维、同理心、专注、构思、原型、测试
design thinking, Empathize, Focus, Ideate, Prototype, Test
定义、同理心、专注、构思、原型、测试
同理心、同理心、专注、构思、原型、测试
构思,移情,焦点,构思,原型,测试
原型设计、同理心、专注、构思、原型、测试
测试、同理心、专注、构思、原型、测试
工作方式,同理心,专注,构思,原型,测试
defining, Empathize, Focus, Ideate, Prototype, Test
empathizing, Empathize, Focus, Ideate, Prototype, Test
ideation, Empathize, Focus, Ideate, Prototype, Test
prototyping, Empathize, Focus, Ideate, Prototype, Test
testing, Empathize, Focus, Ideate, Prototype, Test
way of working, Empathize, Focus, Ideate, Prototype, Test
细节
details
探索,探索细节和选项
填写故事地图,填写缺失的详细信息
离开直到大局完成,讲述你的用户的故事
exploring, Explore Details and Options
filling in for story map, Fill in Missing Details
leaving until big picture is completed, Tell Your Users’ Stories
开发周期
development cycles
在团队审查中讨论,作为一个团队审查
计划,故事实际上就像小行星
规划配方,分裂和变薄
discussing in team review, Review as a Team
planning for, Stories Are Actually Like Asteroids
planning recipe, Split and Thin
开发合作伙伴,Build to Learn
development partners, Build to Learn
发展战略
development strategy
计划,故事实际上就像小行星
切出,使用软件更难
planning, Stories Are Actually Like Asteroids
slicing out, With Software It’s Harder
发现,验证学习使用发现来建立共同理解——发现是为了建立共同理解
discovery, Validated Learning, Using Discovery to Build Shared UnderstandingDiscovery Is for Building Shared Understanding
活动、讨论和工件,发现活动、讨论和工件
发现团队与其他人的协作,发现团队需要很多其他人才能成功
跨职能团队寻找正确的解决方案,有价值 - 可用 - 可行
discovering a minimum viable solution,发现最小可行解决方案
三个朋友中的发现团队成员,三个朋友
讨论机会、深入挖掘、丢弃它或思考它
设想您的解决方案,3. 设想您的解决方案
基本步骤,发现的四个基本步骤
通过示例和旅程探索想法,玩“What-About”
构建想法,1. 构建想法
最小化和规划,4. 最小化和规划
要问和回答的问题,发现与构建软件无关
在利益相关者产品审查中审查,与您组织中的其他人一起审查
故事讨论和分裂,故事实际上就像小行星
时间预算,在团队审查中讨论,作为一个团队审查
了解客户和用户,2.了解客户和用户
使用验证学习,使用发现进行验证学习——故事和故事地图?
using to build shared understanding,发现是为了建立共同的理解
activities, discussions, and artifacts, Discovery Activities, Discussions, and Artifacts
collaboration of discovery team with others, A Discovery Team Needs Lots of Others to Succeed
cross-functional teams finding right solution, Valuable-Usable-Feasible
discovering a minimum viable solution, Discover a Minimum Viable Solution
discovery team member in three amigos, The Three Amigos
discussing opportunities, Dig Deeper, Trash It, or Think About It
envisioning your solution, 3. Envision Your Solution
essential steps in, Four Essential Steps to Discovery
exploring ideas using examples and journeys, Play “What-About”
framing the idea, 1. Frame the Idea
minimizing and planning, 4. Minimize and Plan
questions to ask and answer, Discovery Isn’t About Building Software
reviewing in stakeholder product review, Review with Others in Your Organization
story discussion and splitting, Stories Are Actually Like Asteroids
time budgeted for, discussing in team review, Review as a Team
understanding customers and users, 2. Understand Customers and Users
using for validated learning, Using Discovery for Validated LearningStories and Story Maps?
using to build shared understanding, Discovery Is for Building Shared Understanding
记录对话、Talk 和 Doc创建度假照片
documenting conversations, Talk and Doc, Create Vacation Photos
文件
documents
完美,尝试写作,停止尝试编写完美文档
好文件与度假照片的相似性,好文件就像度假照片
使用帮助记忆,文档帮助记忆
perfect, trying to write, Stop Trying to Write Perfect Documents
similarity of good documents to vacation photos, Good Documents Are Like Vacation Photos
using to aid memory, Document to Help Remember

E

同理心、同理心、专注、构思、原型、测试
empathizing, Empathize, Focus, Ideate, Prototype, Test
残局策略,开局、中局和残局策略
endgame strategy, Opening-, Mid-, and Endgame Strategy
够了,够了
enough, Enough
设想解决方案,3. 设想您的解决方案发现活动、讨论和工件
envisioning the solution, 3. Envision Your Solution, Discovery Activities, Discussions, and Artifacts
史诗,史诗是有时用来打人的大石头
epics, Epics Are Big Rocks Sometimes Used to Hit People
估计
estimation
关于多长时间的对话,真正谈论什么的清单
故事卡、散热器和冰箱的估算、尺寸或预算
估计开发时间,就机会进行对话
在客户-供应商反模式中,三个朋友
测量是良好估计的关键,良好估计的另一个秘密
开发时间估算,良好估算的秘诀
conversations about how long, A Checklist of What to Really Talk About
estimate, size, or budget on story cards, Radiators and Ice Boxes
estimating development time, Have Conversations About Opportunities
in client-vendor anti-pattern, The Three Amigos
measurement as key to good estimates, The Other Secret to Good Estimation
time estimates for development, The Secret to Good Estimation
评估构建的软件,评估每一件
evaluating built software, Evaluate Each Piece
产品发布后继续,Release and Keep Evaluating
与业务利益相关者一起评估,与业务利益相关者一起评估
与用户和客户一起评估,与用户和客户一起评估
continuing after product release, Release and Keep Evaluating
with business stakeholders, Evaluate with Business Stakeholders
with users and customers, Evaluate with Users and Customers
实验, 最小化,真正最小化你的实验
experiments, minimizing, Really Minimize Your Experiments
极限编程,讲更好的故事
Extreme Programming, Telling Better Stories
尖峰,发现最小可行解决方案
spikes, Discover a Minimum Viable Solution

F

F

Fabricant, Robert,软件不是重点
Fabricant, Robert, Software Isn’t the Point
按时完成,计划按时完成——现在怎么办?
finishing on time, Plan to Finish on TimeNow What?
设想整个产品,达芬奇会做什么?
迭代和增量思维,Iterative AND Incremental
管理你的时间预算,管理你的预算
不释放每一片,不要释放每一片
opening-, mid-, and endgame strategy, Opening-, Mid-, and Endgame 策略
良好估计的其他秘密,良好估计的其他秘密
planning to build piece by piece,计划逐个建造
风险,重要性,一切都与风险有关
良好估计的秘密,良好估计的秘密
在地图上切出发展战略,在地图上切出你的发展战略
逐步讲述功能的故事,告诉团队
envisioning the whole product, What Would da Vinci Do?
iterative and incremental thinking, Iterative AND Incremental
managing your time budget, Manage Your Budget
not releasing each slice, Don’t Release Each Slice
opening-, mid-, and endgame strategy, Opening-, Mid-, and Endgame Strategy
other secret to good estimates, The Other Secret to Good Estimation
planning to build piece by piece, Plan to Build Piece by Piece
risk, importance of, It’s All About Risk
secret to good estimation, The Secret to Good Estimation
slicing out development strategy in a map, Slice Out Your Development Strategy in a Map
telling feature’s story step by step, Tell It to the Team
鱼缸协作模式,人群不协作
fishbowl collaboration pattern, Crowds Don’t Collaborate
平面积压陷阱,映射帮助大团队建立共识
flat backlog trap, Mapping Helps Big Groups Build Shared Understanding
注重结果
focusing on outcomes
切出最小可行产品发布,切出最小可行产品发布
切出发布路线图,切出发布路线图
slicing out a minimum viable product release, Slice Out a Minimum Viable Product Release
slicing out a release roadmap, Slice Out a Release Roadmap
FORUM Credit Union,这很神奇——真的,真的很神奇
FORUM Credit Union, This Is Magic—Really, It Is
构建想法,构建您的想法1. 构建想法发现活动,讨论和工件
framing the idea, Frame Your Idea, 1. Frame the Idea, Discovery Activities, Discussions, and Artifacts
构建问题,使用软件更难
framing the problem, With Software It’s Harder
功能质量,检查工作结果
functional quality, Inspect the Results of Your Work
功能性行走骨架,计划逐件搭建
functional walking skeleton, Plan to Build Piece by Piece
功能级任务,我只是更注重细节
functional-level tasks, I’m Just More Detail-Oriented

G

G

Globo.com,计划减少建设
Globo.com, Plan to Build Less
去/不去的决定,从机会开始,就机会进行对话
go/no-go decision, Start with Opportunities, Have Conversations About Opportunities
关于机会,机会不应该是委婉的说法
on opportunities, Opportunity Shouldn’t Be a Euphemism
目标水平,我只是更注重细节
goal level, I’m Just More Detail-Oriented
目标
goals
最小化建造数量,描述您的客户和用户
按重要性排序,构思你的想法
minimizing amount to be built, Describe Your Customers and Users
ordering by importance, Frame Your Idea
Good-Better-Best 游戏,Split and Thin
Good-Better-Best game, Split and Thin
猜测,开始产品设计,从猜测开始
guessing, starting product design with, Start by Guessing

H

H

如何,对话,真正谈论什么的清单
how, conversations about, A Checklist of What to Really Talk About

大号

L

大规模开发上下文,使用故事地图,The Map Is Just the Beginning
large-scale development context, using story mapping, The Map Is Just the Beginning
精益创业,经过验证的短学习循环
Lean Startup, Short Validated Learning Loops
build-measure-learn,重新思考你的解决方案和你的假设
designing and build a small test,设计和构建小型测试
它如何改变产品设计,精益创业思维如何改变产品设计
通过与客户和用户一起运行测试来衡量,通过与客户和用户一起运行测试来衡量
命名您的风险假设,命名您的风险假设
重新思考解决方案和假设,重新思考您的解决方案和假设
从猜测开始,从猜测开始
通过工作软件验证学习,它并不总是软件
build-measure-learn, Rethink Your Solution and Your Assumptions
designing and building a small test, Design and Build a Small Test
how it changes product design, How Lean Startup Thinking Changes Product Design
measuring by running test with customers and users, Measure by Running Your Test with Customers and Users
naming your risky assumptions, Name Your Risky Assumptions
rethinking solutions and assumptions, Rethink Your Solution and Your Assumptions
starting by guessing, Start by Guessing
validated learning over working software, It’s Not Always Software
精益创业 (Ries),新的 MVP 根本不是产品!
The Lean Startup (Ries), The New MVP Isn’t a Product at All!
学习
learning
在你建造之后,从你建造的一切中学习
够了,够了
learning from release to users,Learn from Release to Users
向用户学习,向用户学习
成果如期,成果如期
团队评审, Review as a Team
与组织中的其他人一起审查,与组织中的其他人一起审查
最佳学习实践,Template Zombies and the Snowplow
开发或研究(尖峰),发现最小可行解决方案
在精益创业方法中,重新思考你的解决方案和你的假设
验证(见验证学习)
after you build, Learn from Everything You Build
enough, Enough
learning from release to users, Learn from Release to Users
learning from users, Learn from Users
outcomes on a schedule, Outcomes on a Schedule
review as a team, Review as a Team
review with others in the organization, Review with Others in Your Organization
best learning practices, Template Zombies and the Snowplow
development or research for (spikes), Discover a Minimum Viable Solution
in Lean Startup approach, Rethink Your Solution and Your Assumptions
validated (see validated learning)
学得更快
learning faster
为学习而建造,为学习而建造
客户/用户对原型的反应,注意人们所说的他们想要什么
讨论机会,从讨论你的机会开始
以错误的方式做事,如何以错误的方式做事
迭代直到产品可行Iterate Until Viable
最小化你的实验,真正地最小化你的实验
学习原型,学习原型
验证学习策略,验证学习
验证问题,验证问题
building to learn, Build to Learn
customer/user reactions to prototype, Watch Out for What People Say They Want
discussing the opportunity, Start by Discussing Your Opportunity
doing it the wrong way, How to Do It the Wrong Way
iterating until product is viable, Iterate Until Viable
minimizing your experiments, Really Minimize Your Experiments
prototyping to learn, Prototype to Learn
validated learning strategy, Validated Learning
validating the problem, Validate the Problem
学习策略
learning strategies
为学习而建造,为学习而建造
切出,使用软件更难
building to learn, Build to Learn
slicing out, With Software It’s Harder
莱维特、加里、加里和扁平积压的悲剧
Levitt, Gary, Gary and the Tragedy of the Flat Backlog
Liquidnet,计划学得更快
Liquidnet, Plan to Learn Faster
文字,电话游戏
literals, The Telephone Game

M

绘制大图,使用软件更难
mapping the big picture, With Software It’s Harder
地图,2. 组织你的故事
maps, 2. Organize Your Story
(另见故事地图;故事地图)
叙事旅程地图,映射用户今天的工作方式
在故事工作坊中使用简单地图,在故事工作坊中使用简单地图
使用评估发布准备情况,使用地图评估发布准备情况
可视化进度,使用地图可视化进度
(see also story mapping; story maps)
narrative journey map, Map how users work today
using simple maps in story workshops, Use Simple Maps During Story Workshops
using to evaluate release readiness, Use a Map to Evaluate Release Readiness
visualizing progress with, Use a Map to Visualize Progress
测量
measurement
良好估计的重要性,良好估计的另一个秘密
在精益创业中,重新思考你的解决方案和你的假设
故事卡、散热器和冰箱的指标
与客户和用户一起运行产品测试,通过与客户和用户一起运行测试来衡量
使用指标来了解人们是否/如何使用产品,发布并继续评估
importance to good estimates, The Other Secret to Good Estimation
in Lean Startup, Rethink Your Solution and Your Assumptions
metrics on story cards, Radiators and Ice Boxes
running product test with customers and users, Measure by Running Your Test with Customers and Users
using metrics to learn if/how people use the product, Release and Keep Evaluating
会议、工作坊故事
meetings, Workshopping Stories
中局策略,开局、中局和残局策略
midgame strategy, Opening-, Mid-, and Endgame Strategy
最小化和规划,4. 最小化和规划发现活动、讨论和工件
minimizing and planning, 4. Minimize and Plan, Discovery Activities, Discussions, and Artifacts
优先排序,优先排序的秘诀
prioritization, The secret to prioritization
最小可行产品(参见 MVP)
minimum viable product (see MVP)
最小可行产品实验 (MVPe)、验证学习
minimum viable product experiment (MVPe), Validated Learning
最小可行解决方案(参见 MVS)
minimum viable solution (see MVS)
最小值,定义,为什么我们对 MVP 争论如此之多
minimum, defining, Why We Argue So Much About MVP
蒙娜丽莎策略,为学习而建造分解大蛋糕
Mona Lisa strategy, Build to Learn, Breaking Down a Big Cake
早上地图练习,在家里或工作中试试这个
morning map exercise, Do Try This at Home, or at Work
MVP(最小可行产品)
MVP (minimum viable product)
不同的定义,为什么我们对 MVP 争论如此之多
迭代直到可行,迭代直到可行
最小化你的实验,真正地最小化你的实验
differing definitions of, Why We Argue So Much About MVP
iterating until viable, Iterate Until Viable
minimizng your experiments, Really Minimize Your Experiments
MVPe(最小可行产品实验)、验证学习
MVPe (minimum viable product experiment), Validated Learning
MVS(最小可行解决方案),为什么我们对 MVP 争论如此之多大小总是很重要使用发现进行验证学习
MVS (minimum viable solution), Why We Argue So Much About MVP, Size Always Matters, Using Discovery for Validated Learning
发现,发现最小可行解决方案
discovering, Discover a Minimum Viable Solution

N

叙事流程,映射帮助大团体建立共同理解2. 组织你的故事
narrative flow, Mapping Helps Big Groups Build Shared Understanding, 2. Organize Your Story
寻找流量,保持流量
finding the flow, Keep the Flow
叙事旅程地图,映射用户今天的工作方式
narrative journey map, Map how users work today
NASA 火星气候轨道器,电话游戏坠毁
NASA Mars Climate Orbiter, crash of, The Telephone Game
不走的决定,从机会开始深入挖掘,丢弃它,或者考虑一下
no-go decision, Start with Opportunities, Dig Deeper, Trash It, or Think About It
非功能性需求,电话游戏
nonfunctional requirements, The Telephone Game

O

奥巴马竞选仪表板,在故事研讨会期间使用简单的地图
Obama Campaign Dashboard, Use Simple Maps During Story Workshops
奥巴马,巴拉克,在故事研讨会上使用简单的地图
Obama, Barack, Use Simple Maps During Story Workshops
开局策略, Opening-, Mid-, and Endgame Strategy
opening strategy, Opening-, Mid-, and Endgame Strategy
机会,从机会开始——挑剔
opportunities, Start with OpportunitiesBe Picky
挑剔,Be Picky
用于评估、深入挖掘、丢弃或思考的画布方法
空间流动、深入挖掘、丢弃或思考
Diging deeper , trashing, or thinking about, Dig Deeper, Trash It, or Think About It 深入挖掘,破坏或思考
去/不去的决定,机会不应该是委婉的说法
进行对话,就机会进行对话
在故事讨论和分裂阶段,故事实际上像小行星
从开始,从机会开始
故事地图和,故事地图和机会
being picky about, Be Picky
canvas approach to sizing up, Dig Deeper, Trash It, or Think About It
flow of spaces in, Dig Deeper, Trash It, or Think About It
digging deeper, trashing, or thinking about, Dig Deeper, Trash It, or Think About It
go/no-go decisions on, Opportunity Shouldn’t Be a Euphemism
having conversations about, Have Conversations About Opportunities
in story discussion and splitting stage, Stories Are Actually Like Asteroids
starting with, Start with Opportunities
story mapping and, Story Mapping and Opportunities
机会评估模板,深入挖掘,丢弃它,或思考它
Opportunity Assessment template, Dig Deeper, Trash It, or Think About It
机会积压,从机会开始,就机会进行对话
opportunity backlog, Start with Opportunities, Have Conversations About Opportunities
组织概况, 创建,创建组织概况或 orgzonas
organizational profiles, creating, Create organizational profiles or orgzonas
Osterwalder, Alexander,深入挖掘,丢弃它,或者思考它
Osterwalder, Alexander, Dig Deeper, Trash It, or Think About It
结果,软件不是重点
outcomes, Software Isn’t the Point
评估是否达到目标结果,发布并继续评估
最大化,少建
按计划发布,按计划结果
优先而不是功能,不要优先功能 - 优先结果
切出相关的任务,5. 切出帮助你达到特定结果的任务
evaluating if target outcomes were met, Release and Keep Evaluating
maximizing, Build Less
on scheduled releases, Outcomes on a Schedule
prioritizing instead of features, Don’t Prioritize Features—Prioritize Outcomes
slicing out tasks relevant to, 5. Slice Out Tasks That Help You Reach a Specific Outcome
结果,专注于,总是太多
outcomes, focusing on, There’s Always Too Much
输出,软件不是重点
output, Software Isn’t the Point
最小化,少建
minimizing, Build Less
上手,团队审查
overhand, Review as a Team

P

P

模式,讲述整个故事
patterns, Telling the Whole Story
人物角色,素描,素描简单人物角色
personas, sketching, Sketch simple personas
Pigneur、Yves、深入挖掘、丢弃它或思考它
Pigneur, Yves, Dig Deeper, Trash It, or Think About It
规划
planning
开发周期规划秘诀,拆分和细化
发展战略,故事实际上像小行星
在团队审查中进行评估,作为一个团队进行审查
对于下一个开发周期,Stories Are Actually Like Asteroids
冲刺或迭代计划,冲刺或迭代计划?
development cycle planning recipe, Split and Thin
development strategy, Stories Are Actually Like Asteroids
evaluating in team review, Review as a Team
for next development cycle, Stories Are Actually Like Asteroids
sprint or iteration planning, Sprint or Iteration Planning?
计划少建,计划少建
planning to build less, Plan to Build Less
创建较小的实验和原型,新的 MVP 根本不是产品!
MVP(最小可行产品)的定义,为什么我们对 MVP 争论如此之多
找到一个更小的可行版本,这就是魔法——真的,它是
优先考虑结果而不是功能,不要优先考虑功能——优先考虑结果
切出最小可行产品发布,切出最小可行产品发布
切出发布路线图,切出发布路线图
creating smaller experiments and prototypes, The New MVP Isn’t a Product at All!
definition of MVP (minimum viable product), Why We Argue So Much About MVP
finding a smaller viable release, This Is Magic—Really, It Is
prioritizing outcomes rather than features, Don’t Prioritize Features—Prioritize Outcomes
slicing out a minimum viable product release, Slice Out a Minimum Viable Product Release
slicing out a release roadmap, Slice Out a Release Roadmap
可预测不可预测,计划逐个构建
predictably unpredictables, Plan to Build Piece by Piece
优先次序
prioritization
确定结果的优先级,制定发布路线图
优先处理待办事项列表中的用户故事,地图只是一个开始
的秘密,优先排序的秘密
prioritizing outcomes, Slice Out a Release Roadmap
prioritizing user stories in the backlog, The Map Is Just the Beginning
secret of, The secret to prioritization
问题,验证,验证问题
problem, validating, Validate the Problem
产品积压,1. 卡片使用发现来建立共同理解
product backlog, 1. Card, Using Discovery to Build Shared Understanding
产品开发
product development
的目标,请先阅读本文
goal of, Read This First
产品发现,验证学习
product discovery, Validated Learning
确定有价值的、可用的和可行的产品,有价值-可用-可行
Workiva 示例,计划按时完成
identifying a valuable, usable, and feasible product, Valuable-Usable-Feasible
Workiva example, Plan to Finish on Time
产品经理,不同的人,不同的对话
product managers, Different People, Different Conversations
产品负责人
product owners
作为生产者,产品负责人作为生产者
领导小型跨职能发现团队,有价值-可用-可行
Rock Breakers的职责
as producers, Product Owner as Producer
leading small, cross-functional discovery team, Valuable-Usable-Feasible
responsibilities of, Rock Breakers
进步
progress
使用工具跟踪,跟踪
使用地图可视化,使用地图可视化进度
tracking using tools, Tracking
visualizing using a map, Use a Map to Visualize Progress
项目经理
project managers
对话,不同的人,不同的对话
识别有价值的、可用的和可行的产品,有价值-可用-可行
conversations for, Different People, Different Conversations
identifying valuable, usable, and feasible product, Valuable-Usable-Feasible
Project Phoenix,探索细节和选项
Project Phoenix, Explore Details and Options
原型制作,要学习的原型,移情,专注,构思,原型,测试
prototyping, Prototype to Learn, Empathize, Focus, Ideate, Prototype, Test

Q

质量
quality
讨论,检查你的工作结果
检查构建的每个解决方案,评估每个部分
discussions about, Inspect the Results of Your Work
examining for each soltuion built, Evaluate Each Piece
问题
questions
在对话中识别和讨论,真正谈论什么的清单
在发现中提问和回答,发现与构建软件无关
identifying and discussing in conversations, A Checklist of What to Really Talk About
to ask and answer in discovery, Discovery Isn’t About Building Software

R

R

RAC Insurance,澳大利亚珀斯,Sprint 还是 Iteration Planning?
RAC Insurance, Perth, Australia, Sprint or Iteration Planning?
Refine , defining, and build, Refine, Define, and Build——在故事研讨会中使用简单的地图
refining, defining, and building, Refine, Define, and BuildUse Simple Maps During Story Workshops
卡片和对话,卡片, 对话, 更多卡片, 更多对话...
切割和抛光,切割和抛光
在故事对话中包括太多人,人群不合作
拆分和细化,拆分和细化
冲刺或迭代计划,冲刺或迭代计划?
使用地图可视化进度,使用地图可视化进度
在故事工作坊中使用简单地图,在故事工作坊中使用简单地图
在交付期间使用您的故事地图,在交付期间使用您的故事地图
工作坊故事,工作坊故事
cards and conversations, Cards, Conversation, More Cards, More Conversations…
cutting and polishing, Cutting and Polishing
including too many people in in story conversations, Crowds Don’t Collaborate
splitting and thinning, Split and Thin
sprint or iteration planning, Sprint or Iteration Planning?
using a map to visualize progress, Use a Map to Visualize Progress
using simple maps in story workshops, Use Simple Maps During Story Workshops
using your story map during delivery, Use Your Story Map During Delivery
workshopping stories, Workshopping Stories
排练映射,具有挑战性的假设,故事映射和机会
rehearsal mapping, challenging assumptions with, Story Mapping and Opportunities
Reichelt, Leisa,碎石者
Reichelt, Leisa, Rock Breakers
释放积压,发现最小可行解决方案
release backlog, Discover a Minimum Viable Solution
发布路线图,切出发布路线图
release roadmap, Slice Out a Release Roadmap
发布策略,切片,使用软件更难
release strategy, slicing out, With Software It’s Harder
发布
releases
learning from release to users,Learn from Release to Users
按计划,按计划结果
使用地图评估准备情况,使用地图评估发布准备情况
learning from release to users, Learn from Release to Users
on a schedule, Outcomes on a Schedule
using a map to evaluate readiness, Use a Map to Evaluate Release Readiness
远程协作,工具,建立共同理解
remote collaboration, tools for, Building Shared Understanding
要求,现在和以后肯特颠覆性的简单想法三个朋友
requirements, Now and Later, Kent’s Disruptively Simple Idea, The Three Amigos
糟糕的需求,Kent 颠覆性的简单想法为学习而构建
需求收集角色的业务分析师,产品负责人作为生产者
被误解,电话游戏
停止对话,更多关于可怕的“R”字
bad requirements, Kent’s Disruptively Simple Idea, Build to Learn
business analyst in requirements gathering role, Product Owner as Producer
misinterpreted, The Telephone Game
stopping conversations, More on the Dreaded “R” Word
评论
reviews
团队审查软件构建,作为一个团队审查
与组织中的其他人一起审查,与组织中的其他人一起审查
team review of software builds, Review as a Team
with others in your organization, Review with Others in Your Organization
Ries、Eric,新 MVP 根本不是产品!,验证学习,短验证学习循环
Ries, Eric, The New MVP Isn’t a Product at All!, Validated Learning, Short Validated Learning Loops
风险
risk
在故事地图中展示,管理您的预算
处理的重要性,一切都与风险有关
exposing in story maps, Manage Your Budget
importance of dealing with, It’s All About Risk
岩,破岩——发布并继续评估
rock breaking, Rock BreakingRelease and Keep Evaluating
epics as big rocks,史诗是大石头,有时用来打人
生命周期,忘掉那些术语,专注于讲故事
故事与岩石的相似性,Stories Are Like Rocks
epics as big rocks, Epics Are Big Rocks Sometimes Used to Hit People
lifecycle, Forget Those Terms and Focus on Storytelling
similarity of stories to rocks, Stories Are Like Rocks

小号

S

扩展用户故事映射,地图只是一个开始
scaling user story mapping, The Map Is Just the Beginning
范围蔓延,映射可帮助您发现故事中的漏洞构建以学习
scope creep, Mapping Helps You Spot Holes in Your Story, Build to Learn
Scrum流程
Scrum process
待办事项梳理或待办事项细化,在交付过程中深入了解每个故事的细节
冲刺回顾和回顾,评估每件作品
冲刺评审,团队评审
backlog grooming or backlog refinement, Dive into the Details of Each Story During Delivery
sprint review and retrospective, Evaluate Each Piece
sprint reviews, Review as a Team
海平面任务,我只是更注重细节
sea-level tasks, I’m Just More Detail-Oriented
顺序、识别、讲述用户的故事
sequence, identifying, Tell Your Users’ Stories
共同理解,讲述用户的故事
shared understanding, Tell Your Users’ Stories
建立,建立共同理解是颠覆性的简单
在大团体中建立,映射作为辅助,映射帮助大团体建立共同理解
使用卡片内容构建,建立共同理解
与客户和用户一起构建,真实尝试
与团队一起建设,告诉团队
定义,电话游戏
良好估算的必要条件,良好估算的秘诀
mapping helping big groups, Mapping Helps Big Groups Build Shared Understanding
using discovery to build, Using Discovery to Build Shared Understanding发现是为了建立共同的理解
building, Building Shared Understanding Is Disruptively Simple
building in large groups, mapping as aid to, Mapping Helps Big Groups Build Shared Understanding
building using cards’ contents, Building Shared Understanding
building with customers and users, Try This for Real
building with the team, Tell It to the Team
defined, The Telephone Game
essential for good estimates, The Secret to Good Estimation
mapping helping big groups with, Mapping Helps Big Groups Build Shared Understanding
using discovery to build, Using Discovery to Build Shared UnderstandingDiscovery Is for Building Shared Understanding
大小,重要性,大小总是很重要
size, importance of, Size Always Matters
解决方案,为什么我们对 MVP 争论如此之多
solutions, Why We Argue So Much About MVP
错了,我们大部分时间都错了
关于更好的解决方案的对话,真正谈论什么的清单
设想,3. 设想您的解决方案发现活动、讨论和工件
playing What-About,玩“What-About”
使用故事地图,映射您的解决方案
using words and pictures,文字和图片
可视化整个体验,文字和图片
在精益创业测试后重新思考,重新思考你的解决方案和你的假设
审查完成的交付工作,与组织中的其他人一起审查
being wrong about, We’re Wrong Most of the Time
conversations about better solutions, A Checklist of What to Really Talk About
envisioning, 3. Envision Your Solution, Discovery Activities, Discussions, and Artifacts
playing What-About, Play “What-About”
using story maps, Map your solution
using words and pictures, Words and pictures
visualizing the whole experience, Words and pictures
rethinking after tests in Lean Startup, Rethink Your Solution and Your Assumptions
reviewing delivery work completed for, Review with Others in Your Organization
规范、冲刺或迭代计划?
specifications, Sprint or Iteration Planning?
尖峰,发现最小可行解决方案
spikes, Discover a Minimum Viable Solution
冲刺计划,冲刺或迭代计划?
sprint planning, Sprint or Iteration Planning?
冲刺评审,团队评审
sprint review, Review as a Team
冲刺回顾和回顾,评估每件作品
sprint review and retrospective, Evaluate Each Piece
利益相关者产品审查,与您组织中的其他人一起审查
stakeholder product review, Review with Others in Your Organization
利益相关者
stakeholders
产品所有权角色中的业务利益相关者,产品所有者作为生产者
对话,真正谈论什么的清单
足够的软件,足够
Evaluating built software with,与业务利益相关者一起评估
business stakeholder in product ownership role, Product Owner as Producer
conversations about, A Checklist of What to Really Talk About
enough software for, Enough
evaluating built software with, Evaluate with Business Stakeholders
故事卡、散热器和冰箱上的状态
status on story cards, Radiators and Ice Boxes
故事,仅此而已
stories, That’s All There Is to It
像蛋糕一样烘焙,像蛋糕一样烘焙故事——分解一个大蛋糕
分解一个大蛋糕,分解一个大蛋糕
创建食谱,创建食谱
打破客户-供应商反模式,三个朋友
定义,讲故事,而不是写故事
定义用户故事,地图只是一个开始
深入了解交付过程中的细节,深入了解交付过程中每个故事的细节
史诗,史诗是有时用来打人的大石头
探索另类故事,3.探索另类故事
在深入研究之前先关注广度,讲述用户的故事
专注于讲故事,忘记那些术语,专注于讲故事
使用的目标,请先阅读本文
在经过验证的学习、故事和故事地图中?
许多组件,这很复杂
负责撰写所有故事的产品负责人,Rock Breakers
合适的尺寸,尺寸始终很重要
与小行星的相似性,故事实际上就像小行星
不要为小事出汗,不要为小事出汗
重组分裂的故事,重组破碎的岩石
分裂的故事,故事实际上就像小行星
与岩石相似,故事就像岩石
拆分和细化,拆分和细化
Good-Better-Best 游戏,Split and Thin
从机会开始,从机会开始
讲述并找出你的想法中的漏洞,讲述你的用户的故事
讲更好的故事,讲更好的故事——有很多值得担心的事情
创建假期照片,创建假期照片
模板僵尸和扫雪机, Template Zombies and the Snowplow
使用 Connextra 模板,Connextra 的酷模板
讲述整个故事,讲述整个故事
讲述,而不是写作,肯特颠覆性的简单想法
主题组织故事组,主题组织故事组
用来驱动任何东西的制作,它并不总是软件
baking like a cake, Bake Stories Like CakeBreaking Down a Big Cake
breaking down a big cake, Breaking Down a Big Cake
creating a recipe, Create a Recipe
breaking client-vendor anti-pattern, The Three Amigos
defined, Telling Stories, Not Writing Stories
defining user stories, The Map Is Just the Beginning
diving into details of during delivery, Dive into the Details of Each Story During Delivery
epics, Epics Are Big Rocks Sometimes Used to Hit People
exploring alternative stories, 3. Explore Alternative Stories
focusing on breadth before diving into its depth, Tell Your Users’ Stories
focusing on storytelling, Forget Those Terms and Focus on Storytelling
goal of using, Read This First
in validated learning, Stories and Story Maps?
many components of, This Is Complicated
product owner responsible for writing all stories, Rock Breakers
right size for, Size Always Matters
similarity to asteroids, Stories Are Actually Like Asteroids
not sweating small stuff, Don’t Sweat the Small Stuff
reassembling split stories, Reassembling Broken Rocks
splitting stories, Stories Are Actually Like Asteroids
similarity to rocks, Stories Are Like Rocks
splitting and thinning, Split and Thin
Good-Better-Best game, Split and Thin
starting with opportunities, Start with Opportunities
taling through and finding holes in your thinking, Tell Your Users’ Stories
telling better stories, Telling Better StoriesIt’s a Lot to Worry About
creating vacation photos, Create Vacation Photos
template zombies and the snowplow, Template Zombies and the Snowplow
using Connextra template, Connextra’s Cool Template
telling the whole story, Telling the Whole Story
telling, not writing, Kent’s Disruptively Simple Idea
themes organizaing groups of stories, Themes Organize Groups of Stories
using to drive the making of anything, It’s Not Always Software
故事映射,前言这很复杂
story mapping, Preface, This Is Complicated
和机会,故事地图和机会
作为发现的帮助,发现最小可行解决方案
创建故事地图,您已经知道如何操作–使用软件更难
提炼你的地图以制作主干,4. 提炼你的地图以制作主干
探索另类故事,3.探索另类故事
现在和以后的地图,这是现在的地图,而不是以后的地图
组织你的故事,2. 组织你的故事
切出与特定结果相关的任务,5. 切出可帮助您达到特定结果的任务
重要概念的总结,就是这样!你已经学会了所有重要的概念
尝试早上的地图练习,在家里或工作中试试这个
了解客户现在的工作方式,真实尝试
使用故事地图,地图只是一个开始
一步一步地写故事,1. 一步一步地写出你的故事
描述您的客户和用户,描述您的客户和用户
探索细节和选项,探索细节和选项
暴露风险,管理您的预算
专注于讲述,而不是写作,故事,Simple Isn't Easy
关注结果,总是太多
对于功能,计划按时完成
构思你的想法,构思你的想法
帮助您发现故事中的漏洞,映射可帮助您发现故事中的漏洞
增加频率和保真度,管理您的预算
肯特的简单想法,肯特颠覆性的简单想法
不要过度,不要过度映射
扩展用户故事映射,地图只是一个开始
六个简单的步骤,使用软件更难
谈话和医生,谈话和医生
讲述用户的故事,讲述用户的故事
思考、写作、解释和放置,Talk and Doc
and opportunities, Story Mapping and Opportunities
as aid to discovery, Discover a Minimum Viable Solution
creating a story map, You Already Know HowWith Software It’s Harder
distilling your map to make a backbone, 4. Distill Your Map to Make a Backbone
exploring alternative stories, 3. Explore Alternative Stories
now and later maps, It’s a Now Map, Not a Later Map
organizing your story, 2. Organize Your Story
slicing out tasks relevant to a specific outcome, 5. Slice Out Tasks That Help You Reach a Specific Outcome
summary of important concepts, That’s It! You’ve Learned All the Important Concepts
trying the morning map exercise, Do Try This at Home, or at Work
understanding how customers work now, Try This for Real
using story maps, The Map Is Just the Beginning
writing story a step at a time, 1. Write Out Your Story a Step at a Time
describing your customers and users, Describe Your Customers and Users
exploring details and options, Explore Details and Options
exposing risk, Manage Your Budget
focus on telling, not writing, stories, Simple Isn’t Easy
focusing on outcomes, There’s Always Too Much
for a feature, Plan to Finish on Time
framing your idea, Frame Your Idea
helping you spot holes in your story, Mapping Helps You Spot Holes in Your Story
increasing frequency and fidelity of, Manage Your Budget
Kent’s simple idea, Kent’s Disruptively Simple Idea
not overdoing, Don’t Overdo the Mapping
scaling user story mapping, The Map Is Just the Beginning
six simple steps to, With Software It’s Harder
talk and doc, Talk and Doc
telling your users’ stories, Tell Your Users’ Stories
think, write, explain, and place, Talk and Doc
故事地图
story maps
主干,映射帮助大团体建立共同理解
在经过验证的学习、故事和故事地图中?
跨多个团队映射以可视化依赖关系,映射有助于大团队建立共同理解
在许多用户和系统的叙述流中映射,映射帮助大团体建立共同理解
在整个可交付版本中映射,映射帮助大团队建立共识
映射你的解决方案,映射你的解决方案
在交付期间使用,在交付期间使用您的故事地图
backbone, Mapping Helps Big Groups Build Shared Understanding
in validated learning, Stories and Story Maps?
map across multiple teams to visualize dependencies, Mapping Helps Big Groups Build Shared Understanding
map in narrative flow across many users and systems, Mapping Helps Big Groups Build Shared Understanding
map in whole deliverable releases, Mapping Helps Big Groups Build Shared Understanding
mapping your solution, Map your solution
using during delivery, Use Your Story Map During Delivery
故事编号、散热器和冰箱
story number, Radiators and Ice Boxes
故事测试,3.确认
story tests, 3. Confirmation
故事工作坊,在交付、切割和抛光过程中深入了解每个故事的细节
story workshops, Dive into the Details of Each Story During Delivery, Cutting and Polishing
就建造什么达成一致,Workshopping Stories
指挥,工作坊故事
深入研究并考虑各种选择,Workshopping Stories
包括合适的人,Workshopping Stories
Split 和 Thin的结果
食谱,工作坊故事
拆分和细化故事,Workshopping Stories
三个朋友,三个朋友
使用简单地图,在故事研讨会期间使用简单地图
agreeing on what to build, Workshopping Stories
conducting, Workshopping Stories
diving deep and considering options, Workshopping Stories
including the right people, Workshopping Stories
outcomes of, Split and Thin
recipe for, Workshopping Stories
splitting and thinning stories, Workshopping Stories
three amigos, The Three Amigos
using simple maps, Use Simple Maps During Story Workshops
讲故事,建立口头传统,建立讲故事的口头传统
storytelling, building an oral tradition of, Build an Oral Tradition of Storytelling
子任务,我只是更注重细节
subtasks, I’m Just More Detail-Oriented
摘要级任务,我只是更注重细节
summary-level tasks, I’m Just More Detail-Oriented

T

谈话和医生,谈话和医生
talk and doc, Talk and Doc
在 故事工作坊, Workshopping Stories
in story workshops, Workshopping Stories
任务,任务就是我们所做的
tasks, Tasks Are What We Do
聚合到活动中,4. 提炼您的地图以制作主干
细节层次,我只是更注重细节
aggregation into activities, 4. Distill Your Map to Make a Backbone
levels of detail, I’m Just More Detail-Oriented
电话游戏,电话游戏
telephone game, The Telephone Game
模板僵尸,模板僵尸和扫雪机
template zombies, Template Zombies and the Snowplow
测试人员,不同的人,不同的对话
testers, Different People, Different Conversations
在三个朋友中,三个朋友
in three amigos, The Three Amigos
测试
testing
designing and build a small test (精益创业), Design and Build a Small Test
了解你的解决方案是否解决了问题,同理心,专注,构思,原型,测试
与用户/客户一起工作的有意义的软件块,与用户和客户一起评估
软件构建的用户测试,它不适合你
工作软件的用户测试,向用户学习
designing and building a small test (Lean Startup), Design and Build a Small Test
learning if your solution solves a problem, Empathize, Focus, Ideate, Prototype, Test
meaningful chunks of working software with users/customers, Evaluate with Users and Customers
user testing of software builds, It’s Not for You
user testing of working software, Learn from Users
学习联系 (TLC),探索详细信息和选项
The Learning Connection (TLC), Explore Details and Options
主题,主题组织故事组
themes, Themes Organize Groups of Stories
三个朋友,三个朋友
three amigos, The Three Amigos
三个 Cs,Ron Jeffries 和 3 Cs切割和抛光
three Cs, Ron Jeffries and the 3 Cs, Cutting and Polishing
卡片,1.卡片
确认,3.确认
对话,2.对话
cards, 1. Card
confirmation, 3. Confirmation
conversation, 2. Conversation
限时开发、拆分和精简
time-boxed development, Split and Thin
标题(在故事卡上)、散热器和冰箱
title (on story cards), Radiators and Ice Boxes
工具
tools
记录对话中创建的模型或示例,Remembering
为了记录对话,我们需要一张更大的卡片
将故事组织成主题,主题组织故事组
跟踪计划的工作及其进度,Tracking
使用错误的工具或错误的工具,那不是该工具的用途
用于外部化产品可视化,建立共同理解
documenting models or examples created in conversations, Remembering
for documenting conversations, We’re Gonna Need a Bigger Card
organizing stories into themes, Themes Organize Groups of Stories
tracking planned work and its progress, Tracking
using the wrong tool or the tool wrong, That’s Not What That Tool Is For
using to externalize product visualizations, Building Shared Understanding
跟踪, 使用工具,跟踪
tracking, using tools for, Tracking
三合会(核心发现团队),有价值-可用-可行
triad (core discovery team), Valuable-Usable-Feasible
真的,道格,这就是魔法——真的,它是
True, Doug, This Is Magic—Really, It Is

ü

U

UI设计师,不同的人,不同的对话
UI designers, Different People, Different Conversations
昂格尔、吉姆、文字和图片
Unger, Jim, Words and pictures
用户体验质量,检查你的工作结果
user experience quality, Inspect the Results of Your Work
用户故事,讲述更好的故事
user stories, Telling Better Stories
(另见故事)
(see also stories)
用户任务,Tasks Are What We Do
user tasks, Tasks Are What We Do
用户,少建
users, Build Less
对话,真正谈论什么的清单
描述您的用户,描述您的客户和用户
足够的软件,足够
Evaluating built software with,与用户和客户一起评估
研究产品的典型用户,地图只是一个开始
测试软件构建,它不适合你
测试工作软件,向用户学习
理解,2. 理解客户和用户发现活动、讨论和工件
创建组织概况,创建组织概况或 orgzonas
映射用户今天的工作方式, 映射用户今天的工作方式
素描简单的人物角色,素描简单的人物角色
conversations about, A Checklist of What to Really Talk About
describing your users, Describe Your Customers and Users
enough software for, Enough
evaluating built software with, Evaluate with Users and Customers
researching typical users for a product, The Map Is Just the Beginning
testing software builds, It’s Not for You
testing working software with, Learn from Users
understanding, 2. Understand Customers and Users, Discovery Activities, Discussions, and Artifacts
creating organizational profiles, Create organizational profiles or orgzonas
mapping how users work today, Map how users work today
sketching simple personas, Sketch simple personas
用户体验设计师
UX designers
在三个朋友中,三个朋友
可视化整个体验,文字和图片
in three amigos, The Three Amigos
visualizing the whole experience, Words and pictures

V

V

假期照片,创建假期照片
vacation photos, Create Vacation Photos
好文件的相似性,好文件就像度假照片
similarity of good documents to, Good Documents Are Like Vacation Photos
经过验证的学习,它并不总是软件
validated learning, It’s Not Always Software
使用发现,使用发现进行验证学习——故事和故事地图?
大多数时候都错了,我们大多数时候都错了
设计过程,搞砸了,如何搞砸一件好事
同理心、专注、构思、原型和测试,同理心、专注、构思、原型、测试
精益创业,改变产品设计,精益创业思维如何改变产品设计
短验证学习循环,短验证学习循环
故事和故事地图,故事和故事地图?
糟糕的过去,糟糕的过去
using discovery for, Using Discovery for Validated LearningStories and Story Maps?
being wrong most of the time, We’re Wrong Most of the Time
design process, messing up, How to Mess Up a Good Thing
empathize, focus, ideate, prototype, and test, Empathize, Focus, Ideate, Prototype, Test
Lean Startup, changes to product design, How Lean Startup Thinking Changes Product Design
short validated learning loops, Short Validated Learning Loops
stories and story maps, Stories and Story Maps?
the bad old days, The Bad Old Days
验证学习策略,验证学习
validated learning strategy, Validated Learning
验证问题,验证问题
validating the problems, Validate the Problem
有价值的、可用的、可行的产品,Valuable-Usable-Feasible
valuable, usable, and feasible products, Valuable-Usable-Feasible
速度,软件不是重点团队审查
velocity, Software Isn’t the Point, Review as a Team
供应商,客户-供应商反模式,三个朋友
vendors, client-vendor anti-pattern, The Three Amigos
可行的,明确的,为什么我们对 MVP 争论如此之多
viable, defined, Why We Argue So Much About MVP
可视化想法,创建度假照片
visualizing ideas, Create Vacation Photos

Y

耶茨,珍,电话游戏
Yates, Jen, The Telephone Game

版权所有

Colophon

User Story Mapping封面上的动物是一种淡紫色胸卷毛,通常被认为是世界上最美丽的鸟类之一,拥有柔和的羽毛、醒目的田野标记和长长的尾巴飘带。它是肯尼亚和博茨瓦纳的国鸟,在南部非洲的大部分地区相对常见和广泛分布。

The animal on the cover of User Story Mapping is a lilac-breasted roller, often considered one of the most beautiful birds in the world with its pastel plumage, striking field marks, and long tail streamers. It’s the national bird of both Kenya and Botswana, and is relatively common and widespread throughout much of southern Africa.

这些鸟通常是孤独的或成对出现,但在冬季可能会留在小家庭中。它们栖息在树木和杆子顶端的制高点,并在观察猎物接近时保持静止。在落到受害者身上后,它们可能会将猎物击打在岩石上或地面上以将其杀死,然后再将其整个吞下。

These birds are typically solitary or are found in pairs, but may stay in small family groups during the winter months. They perch on high vantage points at the very tops of trees and poles, and stay still while watching for prey to approach. After dropping onto a victim, they may beat their prey against a rock or on the ground to kill it before swallowing it whole.

这些鸟是一夫一妻制(据信终生交配),“roller”这个名字实际上来自鸟类在交配季节使用的空中展示。丁香胸滚筒会从相当高的高度俯冲,然后在空中翻滚,同时发出响亮的叫声以吸引伙伴。

The birds are monogamous (believed to mate for life) and the name “roller” actually comes from the aerial displays the birds use during mating season. Lilac-breasted rollers will dive from a considerable elevation, and then roll in the air while simultaneously letting out a loud call to attract a partner.

O'Reilly 封面上的许多动物都濒临灭绝;所有这些对世界都很重要。要了解有关如何提供帮助的更多信息,请访问animals.oreilly.com

Many of the animals on O’Reilly covers are endangered; all of them are important to the world. To learn more about how you can help, go to animals.oreilly.com.

封面图片来自 Braukhaus Lexicon。封面字体是 URW Typewriter 和 Guardian Sans。文字字体为Adobe Minion Pro;标题字体为 Adob​​e Myriad Condensed;代码字体是 Dalton Maag 的 Ubuntu Mono。

The cover image is from Braukhaus Lexicon. The cover fonts are URW Typewriter and Guardian Sans. The text font is Adobe Minion Pro; the heading font is Adobe Myriad Condensed; and the code font is Dalton Maag’s Ubuntu Mono.

用户故事映射

User Story Mapping

杰夫 巴顿

Jeff Patton

编辑

Editor

玛丽· 特雷瑟勒

Mary Treseler

编辑

Editor

艾米· 乔利摩尔

Amy Jollymore

编辑

Editor

卡拉 易卜拉欣

Kara Ebrahim

编辑

Editor

雷切尔莫纳

Rachel Monaghan

修订记录
2014-09-05首次发布

购买 O'Reilly 书籍可用于教育、商业或促销用途。大多数书籍也有在线版本 ( http://safaribooksonline.com )。如需更多信息,请联系我们的企业/机构销售部:800-998-9938 或

O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or .

Nutshell Handbook、Nutshell Handbook 徽标和 O'Reilly 徽标是 O'Reilly Media, Inc. 的注册商标。User Story Mapping、丁香胸卷轴的图像和相关商业外观是 O'Reilly Media 的商标,公司

Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. User Story Mapping, the image of a lilac-breasted roller, and related trade dress are trademarks of O’Reilly Media, Inc.

制造商和销售商用来区分其产品的许多名称都被声明为商标。如果这些名称出现在本书中,并且 O'Reilly Media, Inc. 知道商标声明,则这些名称已印在大写字母或首字母大写字母中。

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps.

尽管在准备本书时采取了一切预防措施,但出版商和作者对错误或遗漏,或因使用此处包含的信息而造成的损害不承担任何责任。

While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

奥莱利媒体公司

1005 Gravenstein 公路北

1005 Gravenstein Highway North

塞瓦斯托波尔CA 95472

Sebastopol, CA 95472

2014-09-05T17:32:46Z

2014-09-05T17:32:46Z